Re: [TEST/REVIEW/HEADSUP] tty drivers mega-patch

In message <20040714180816.GA5503_at_dhcp50.pn.xcllnt.net>, Marcel Moolenaar write
s:

>> The traditional naming has been the inserted "i" and "l" which I
>> agree is arcane.  I'm not against changing it to ".init" and ".lock"
>> if we can get concensus.
>
>We can create a simple compatibility scheme: If the out argument
>to ttymakeslaves is a string of exactly 1 character, use the old
>naming scheme. Otherwise, a new naming scheme is used. In the old
>scheme, the slave (or out) devices are called cua*. In the new
>scheme the out devices have the name given by the out argument.

If we go the "on demand" route, this is not really an issue because
then we can have both :-)

>> I would prefer to stick to the "tty" and "cua" prefixes however.
>
>I can agree on the tty prefix. I've always disliked the cua prefix,
>simply because it's nonsensical.

Actually it is suns mangling of the well established telecom acronum
"ACU" (Automatic Calling Unit, a box next to your modem which would
pulse dial a number for you.  Initially the numbers were hardcoded
using jumpers in a PTT sealed compartment, later on you could get
permission to send the number to the ACU via a TTL-BCD interface.
The Hayes modems broke the PTT rules in practically all european
countries when they came out.  There's an interesting saga about
the first modem on MCVAX.

>simply because it's nonsensical. It's the kind of prefix you pick
>when all the good (and bad) ones have been used and you randomly
>grab 3 letters from your scrabble box, sigh, and accept that once
>again luck hasn't been on your side :-) :-)

I don't disagree, but it is nontheless what people are used to
by now so I don't think we should change it.

>> The plan is to make them on-demand-devices (clonable) so that they
>> do not clutter up /dev but appear if you access them.  That would
>> leave only the ttyu0 and cuau0 devices.
>
>Yes! I like the cloning.

Cool, I'll work on that then.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.