Re: CVS commit: src/usr.bin/tip

["Perry E. Metzger" <perry%piermont.com@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
> On Mon, Apr 03, 2006 at 05:43:07PM +0900, YAMAMOTO Takashi wrote:
>> > I think this won't work with root on NFS, we don't support the lockd 
>> > protocol
>> > in our NFS client.
>> 
>> because the device in question is local,
>> i don't think NLM is necessary or desirable.
>
> Sure. My concern was that I expected fcntl to return EOPNOPSUPP for files on
> a NFS filesystem, but it seem to work locally anyway (I just tested this).
> So this is not a problem.

Just by way of explanation here, lets keep in mind the application
domain for uucp locking, and why we might not care about it any longer.

25 years ago, a machine would have vast numbers of serial ports and a
"dial-out pool" of modems for contacting other hosts via UUCP, tip and
other applications was a common thing. (I once managed a dial-out pool
with something like thirty or forty lines, used simultaneously for
uucp, cu, and "dial-back" login.)

Today, this sort of thing has entirely disappeared. There are now no
giant modem pools being used among large numbers of people for
multiple applications -- there are, in fact, no multi-application
dial-out modem pools like this at all. (There are a few single
application pools out there used for dial-out fax -- essentially
nothing else connected directly to hosts survives. ISPs use
specialized equipment for their PPP farms, and such farms are
disappearing too.)

tip and cu used to be the way you called up another machine across the
country to use it. Now they are the way you attach to your soekris
over a hard-wired port to load new firmware. The uucp locking stuff
doesn't make any sense any more in a tip/cu context, even if we chose
to leave that code in other parts of our code base. It is a large,
suid based infrastructure that serves no purpose for tip and cu.

Remember what the uucp locking regime was for: you used the locks to
allow you to hunt through the modem pool to find a working modem. That
just isn't going to happen any more. By contrast, the flock locking we
added isn't intended to be used very often in the real world -- it is
just there to prevent accidents, say if two administrators both try
connecting to a serial console at once.

By the way, the tip/cu dial out code is hopelessly obsolete at this
point. It won't really work in practice anyway. If people want to use
it for that purpose, we would need to replace the dial-out code with
chat(8) or something -- the fact that no one has bothered probably
confirms that no one uses it for that purpose any longer.

Perry