Subject: Re: Formal getty replacement yet?
To: None <current-users@NetBSD.ORG>
From: Mike O'Brien <email@example.com>
Date: 12/28/1994 20:57:12
[ On Wed, December 21, 1994 at 11:47:36 (PST), Peter Seebach wrote: ]
> Subject: Re: Formal getty replacement yet?
> I'll put myself firmly in the one-device per device school. I can tolerate
> the minor numbers/density hacks for 1/2 inch tape, though it's ugly. However,
> there is *no* reason for the kernel to take over this monitoring. Most
> visibly, there are cases where it will be wrong. You can decide to ignore
> a lock file. You can wilfully remove it. But if ever, ever, there is a bug
> in the kernel's code for device locking, you can have bigger problems.
This sounds like a good philosophy, but having had practice with both
regimes, I don't agree. Early UNIX systems had such locking systems for
the magtape drive, to make sure one guy didn't scribble on another guy's
backup tape. Occasionally, due to the usual sort of bobble that V6 UNIX
was heir to, the kernel's lock would get stuck "on" and there would be no
using the tape drive till a reboot was done. Well, not exactly...things
being as they were in those days, someone would run 'db' on the kernel
and clear the damn flag.
The point is that that occurrance, even under V6 UNIX with all its bugs,
was quite rare compared to the sort of bobble one sees all the time
with UUCP lock files.
I say, DO put such device locking in the kernel, BUT, provide a utility
to override it if necessary, through, say, a root-only ioctl call.
If the semantics of a device forbid shared use, then the kernel should
enforce those semantics.