Newsgroups: comp.sys.sun.apps,comp.sys.hp,comp.parallel.pvm,comp.sys.dec
Path: ukc!uknet!pipex!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!dsiebert
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Re: Accessing Real Time Clock in workstations (HPs, Suns, Dec Alphas)
Message-ID: <1994Jan26.005700.2572@icaen.uiowa.edu>
Sender: usenet@icaen.uiowa.edu (UseNet News daemon)
Organization: Iowa Computer Aided Engineering Network, University of Iowa
References: <mk9krlINNna0@appserv.Eng.Sun.COM>
Date: Wed, 26 Jan 1994 00:57:00 GMT
Lines: 23
Xref: ukc comp.sys.sun.apps:6144 comp.sys.hp:39123 comp.parallel.pvm:1248 comp.sys.dec:18496

barts@cyber.Eng.Sun.COM (Bart Smaalders) writes:

><Someone is looking for a hardware timer and doesn't believe Solaris 2.[23]
> gettimeofday is adequate>

>Gettimeoday(2) is implemented as a fast trap since Solaris 2.2.  As a result, 
>this call takes about 2->3 microseconds on a SS10 (slightly more on an SS2).
>It returns answers accurate to the resolution of the hardware clock (1 microsecond
>on 4[cmd] platforms).


Could someone explain to me exactly WHY this has to be a system call at all?
It seems to me it would make a GREAT deal of sense to map things like the
hardware clock into a process' address space read-only.  Then you don't need
a system call, or a fast trap, just a simple function call (or perhaps a
millicode stub on the HP)  Many things could benefit here, the whole UAREA of
a process could be mapped read-only without negative effects, I'd think.  Then
getpid() isn't a system call, getuid() isn't, etc., etc.  Is there a reason
why this isn't done?


Doug Siebert || dsiebert@isca.uiowa.edu   ||  Defeat Usenet spool grepping!
Kibo Turkey Greece Macedonia Perl Watcom Mason Clinton Illuminati Fnord Hastur

