[ On Sun, March 22, 1998 at 13:33:03 (+1100), Robert Elz wrote: ]
> Subject: Re: tty layer bogons from the depths of the abyss 
>
>     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).

Yes, the true SunOS-style call-in/call-out devices, which we should now
have, are about the best of the available solutions.

>   | 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.

Indeed, however in the past most such problems happen with commercial
systems for which few users have driver source code, let alone full OS
source code.

Even worse is the situation where very few OS vendors have people smart
enough to work out the logic necessary (I've seen far more broken comm
drivers than working ones....) [or at least the peole they have who are
smart enough don't seem to give a hoot about comm drivers].  Luckily
NetBSD doesn't often suffer this problem, esp. of late!  (Thanks Charles!)

> 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).

Actually it's not quite that simple.  99.9% of competent system
administrators won't change the naming schemes in /dev even if they
think they can.  Indeed for some mappings this is impossible anyway
without having full system source code and access to at least one
competent systems programmer.

Consistent and mnemonic naming is critical.  I'd even argue for putting
things into sub-directories (eg. /dev/ttyin/XXX, /dev/ttyout/XXX), but
of course that's another somewhat religious argument.

> 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).

Such magic can be hidden in well designed and documented library
routines such that any old program can be built to use dialout ports.
User-level hacking like this is much easier than kernel-level hacking,
esp. when the library implements the magic in an easy-to-use function
call that simply mimics the behaviour of the normal fopen() or whatever.

> 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.

I guess it depends on how big your minor-number space is, but I've
always hated drivers that make me split the minor number into bit masks
and device offset counters, esp. when the number of flag bits grows
above one.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>