Isn't it amazing what you find in the manuals?

[Michael "Ford" Ditto]

In article <481 at uncle.UUCP> jbm at uncle.UUCP (John B. Milton) writes:
> LOCKING(2). I always wondered if the UNIXpc had this one, but I
>never had a pressing need for it, so I never tracked it down. One would think
>this would be the first step for a business machine...

The Unix PC has "real" SysV locking (see fcntl(2) and lockf(3)), so
programs should not need locking(2).

> I also wonder why some UNIX systems call it LOCKF(). 

Do they?  SysV's lockf() is the posix-compatible locking facility which
uses the fcntl F_SETLK facility.  I think BSD's lockf is similarly
implemented over their "native" locking system call, flock().  I think
locking(2) was an early experimental version of SysV locking.  It's
called BASSLOCKING in the header files, after John Bass, who wrote the
code, I beleive.

>Alex S. Crain, alex at umbc3.UMBC.EDU just posted
>a list of the known system call access points,
[ ... ]
>Some other ones look interesting. I have seen references, but don't see any
>man pages for:
>
>#define SYS_STTY	31	/* stty()		*/
>#define SYS_GTTY	32	/* gtty()		*/

These are old V6 system calls, equivalent to ioctl(TIOC[GS]ETP), but
superceded by ioctl(TC[GS]ETA).

>And why were both of these called utime()?
>
>#define SYS_UTSSYS	57	/* utime()		*/
>#define SYS_UTIME	30	/* utime()		*/

Probably just a typo.  57 is utssys(), a "catchall" system call used by
ustat() and uname(), and on the Unix PC, setuname().  A function number
is passed specifying which function is desired, along with the args to
that function.  0=uname, 2=ustat, 3=setuname, others=EFAULT.

>Hey Alex, where did your info come from anyway?

perhaps something like:
	echo 'sysent,80?xp' | adb /unix /dev/kmem
(which will also tell you how many args each call gets).  Notice all the
slots reserved for "expansion" system calls, such as socket functions.
They even already have the nargs field filled in; you could probably
guess which was which (or better yet, someone with the TCP/IP software
could tell us).

>I just whipped up a quicky utility to lock a given file. This has it's uses:
>Imagine you're hacking away at 3a.m., and you here the click. Oh, I'm being
>polled. You check. Aaaahhhhh. That was a disconnect! Aaaaahhh. There's a huge
>pile news that just started unbatching...
>
>lock /usr/lib/news/history -z3600 &
>
>Ahhhhh, much better.
>A regular ho-hum user can cause a lot of trouble with this! Consider:
[ other examples of enforcement mode locking causing problems deleted ]

I thought locking() only provided advisory locks.  Have you actually
tried those examples?  I'm not near a Unix PC at the moment so I can't
try it or look at the manual.  If it really does provide enforcement
locking, then yes, it is a serious problem.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford at kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!kenobi!ford
  2nd Edition, June, 1972.		ditto at cbmvax.commodore.com