Date: Mon, 20 Sep 2004 09:38:45 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: arch@FreeBSD.org Subject: [HEADSUP] naming of tty devices. Message-ID: <46041.1095665925@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46041.1095665925>