[ On Tue, December 20, 1994 at 12:47:01 (-0500), Perry E. Metzger wrote: ]
> Subject: Re: /dev/cuaXX (Was: Formal getty replacement yet?) 
>
> I've tried every other scheme out there. Nothing else works even
> remotely as well. Besides, its not a kludge; there are many devices
> for which we have multiple entries in /dev. Tape drives get multiple
> device entries depending on density and rewindingness and we don't get
> upset. Disk drives get different character and block devices and no
> one moans. It all seems plenty unix-like to me.

I agree, if it works, having separate dial-in/dial-out devices, with all
the access control in the driver, is handy.

However most every implementation I've used has some problems with
permitting multiple open()s on such devices, since the driver writer
often gets the semantics wrong.

There's still the added complexity.

And finally, as I've said all along, the lock state is maintained in the
kernel, and the user has little option but a re-boot if anything goes
wrong.

Note that we've already got O_NONBLOCK to manage opening the port when
there's no DCD present, as well as O_EXCL and O_EXLOCK for exclusive
access at the request of the application.

BTW, I think having multiple tape/floppy devices for different densities
is an icky hack too, but having a character and a block device for one
physical device isn't.  Also note that in these cases there's no hidden
lock information being managed inside the kernel (or at least I hope
there isn't!).

I think the K.I.S.S. principle is the best argument here....

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>