[HEADSUP] naming of tty devices.
Roman Kurakin
rik at cronyx.ru
Mon Sep 20 06:12:22 PDT 2004
Just an idea:
Why not to add some general device enumeration for all devices,
especially
if devices would behave the same?
tty%{global_port}
cua%{global_port}
rik
Poul-Henning Kamp wrote:
>I am convinced that it is important that a serial port behaves
>predictably no matter what driver implements it, and this is far
>from the case today. The tty cleanup I'm doing now in preparation
>for being able to pull all the tty stuff out from under Giant
>is more or less a matter of getting the drivers to do the same thing
>by using the same code.
>
>There is one outstanding issue though: Device naming
>
>The traditional BSD naming scheme as far as I can tell was
>
> tty[%{adapter}]%{port}
>
>Sun (?) introduced the "cua" devices (Calling Unit Attachment in case
>you wondered) to allow a modem to be used in both in- and out-going
>direction at once.
>
>Our sio driver, which for many intents and purposes is our reference
>driver, almost follows this convention:
>
> tty[il]d0 + cua[il]a0 = port 0
>
> The 'i' and 'l' reference the "init" and "lock" state respectively.
>
>Other drivers have resorted to various variations of this scheme
>(if they were copy&pasted from sio.c) or rolled their own private
>naming system. In other words: it's a pretty mess right now.
>
>We discussed this naming of tty devices earlier this year (on
>current) and didn't reach a concensus. This is IMO one of those
>areas where there is no "perfect" solution given backwards compatibility
>and therefore the closest to perfect we can get is to define a
>naming scheme which retains as much compatibility as possible and
>stick to it.
>
>My suggestion is the following:
>
> All drivers will offer "tty${something}" devices, and
> generally ${something} will consist of a letter followed
> by a number, possibly in base 36 ([0-9a-z]).
>
> All drivers which attach to external equipment via a serial
> connector should also offer "cua${thesamething}". "Embedded"
> serial ports, pseudo drivers etc, do not have to offer the
> "cua" if DCD state on open is not an issue.
>
> The init and lock devices will be called ${base_device}.[init,lock]
> and they will possibly be provided by on-demand devices so that
> they do not clutter up /dev.
>
>This results in the following major compatibility issues:
>
> sio's cuaa* gets renamed to cuad*
>
> sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock}
>
> ucom's ucom%d gets renamed to ttyU%d
>
> ucom gains cuaU%d and .init and .lock devices.
>
> uart gains cuau%d and .init and .lock devices.
>
>The remaining drivers are pretty obscure and have limited user communities
>and they will just have to live with things getting straigthend out.
>
>
>I'll admit that this should have been done 10 years ago, but better late
>than never.
>
>Well-argued protests or researched alternatives before friday please.
>
>Thanks in advance,
>
>Poul-Henning
>
>
>
More information about the freebsd-arch
mailing list