Date:        Fri, 20 Mar 1998 17:09:49 -0500
    From:        Ken Hornstein <kenh@cmf.nrl.navy.mil>
    Message-ID:  <199803202209.RAA09777@ginger.cmf.nrl.navy.mil>

  | One group loves the cua scheme.  Another group hates it and denounces
  | it as the spawn of Satan.

Count me with the lovers... (or at least, the ones who believe it works
better than any other scheme I've seen).

  | However, there have been a few
  | times where the tty got into a weird state and required a reboot.

I have never seen that, but perhaps you used a different implementation.
In any cases, designs should not be judged by implementation bugs, those
should simply be fixed.

  | I can understand the arguments against it; it moves some locking into
  | the kernel that might be better left to userland,

There have always been arguments between the absolute minimalist kernel types
and the "shove in the universe" (I've seen kernels - not unix - that included
editors...)  The same argument can be made about file locking, device 
management, even processor scheduelling ... almost everyone, even the
minimalists, believe, at least, that users of resources shouldn't need to deal
with the scheduelling issues, whether the kernel does it, or some user level
process takes care of it doesn't, the end user should be able to simply request
and use the resource, the necessary scheduelling should just happen.  (Some
particularly critical embedded systems type applications excepted).

Unix kernels are somewhere in the middle, they are nothing like minimalist,
they're also nothing like some of the older kernels that included everything
anyone could imagine.   I think we can tolerate resource sharing of devices
to be in the kernel.

  | and it's generally
  | not been possible to reset it when it went south (except rebooting,
  | of course :-) ).

More implementation bugs.

  | I believe the general objections to the previous implementations were
  | that they were tied to particular hardware, where this feature really
  | should be made generic and put into the tty layer.

Agreed.


paul@vix.com said:
  | Remembering correspondances between different /dev/{XXX,YYY} pairs
  | which refer to the same physical device but "in different ways" is not
  | my strong point.

Personally, I have never felt the need to remember, though I do agree with
keeping the /dev entry naming consistent (but as that's an operator level
decision anyway - people can name things in /dev anyhow they choose, I don't
see that as critical).

paul@vix.com said:
  | The system of pending opens where getty's open() can continue to block
  | while tip's open() succeeds suits me just fine.  Can we rewind this
  | conversation to that point and have somebody explain just why that's a
  | bad thing?

It means that only "magic" programs can open dialout lines, and that they
have to do that in a way that isn't consistent with the way they open any
other file on the system.   There's no need for only magic programs to be
able to dial, anything should simply be able to open /dev/whatever and do it
(and dual use in/out lines aren't always connected to modems either).


seifert@sequent.com said:
  | You need to open the device in two different ways. What could be
  | cleaner than supplying a flag to the open(2) call? 

Not having to supply a magic flag to the open(2) call.   Cleaner, almost by
definition.

seifert@sequent.com said:
  | Mods to uucp and tip/cu are also trivial.

And it means that my (unusual) uucp simply won't work, because it doesn't
have those trivial mods.   Nor will zllions of other things.   I would like
to be able to do ...

	(
		echo "AT..."
		sleep 1;
		echo "ATDT..."
		sleep 10;
		run come random program using stdin stdout
	) </dev/modem >/dev/modem

without having to make trivial mods to the shell to decognise an open of
/dev/modem and open it a different way than it would any other redirected
stdout.

seifert@sequent.com said:
  | And no /dev pollution.  No wasted major/minor numbers.

Since most of the universe populate /dev with entries for all kinds of random
hardware that they don't own, and will never own, just because it is easier
and simpler for everyone to ship systems with installation scripts that create
the universe in /dev, I don't think I will worry too much about the pollution.
If you want, you can make it /dev/dialer/xxx so just one entry in /dev.

Wasted numbers ... hmm ... I'll have to think about just how serious is
a wasted number.   Certainly, the way Chris Torek described the original UMD
version of this scheme is the right way though ("waste" a major number), the
one thing Sun did wrong was to overload the minor number space.

kre