[HEADSUP] naming of tty devices.
From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 09/20/04
- Previous message: Brooks Davis: "Re: Global (non _KERNEL) place for sockaddr_union?"
- Next in thread: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices."
- Reply: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices."
- Reply: Valentin Nechayev: "Re: [HEADSUP] naming of tty devices."
- Reply: Roman Kurakin: "Re: [HEADSUP] naming of tty devices."
- Reply: Bruce M Simpson: "Re: [HEADSUP] naming of tty devices."
- Reply: Alexey Dokuchaev: "Re: [HEADSUP] naming of tty devices."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: arch@FreeBSD.org Date: Mon, 20 Sep 2004 09:38:45 +0200
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. _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Brooks Davis: "Re: Global (non _KERNEL) place for sockaddr_union?"
- Next in thread: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices."
- Reply: Ruslan Ermilov: "Re: [HEADSUP] naming of tty devices."
- Reply: Valentin Nechayev: "Re: [HEADSUP] naming of tty devices."
- Reply: Roman Kurakin: "Re: [HEADSUP] naming of tty devices."
- Reply: Bruce M Simpson: "Re: [HEADSUP] naming of tty devices."
- Reply: Alexey Dokuchaev: "Re: [HEADSUP] naming of tty devices."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: Sometimes its okay to make someone brake when moving into passing lane
... not naming names, because I really don't remember who said it) said what ...
I interpreted as you should never change lanes to the left and cause ... Provided that
driver is behaving properly. ... to brake if they maintained their cruising speed.
... (rec.autos.driving) - Re: [HEADSUP] naming of tty devices.
... >is more or less a matter of getting the drivers to do the same thing ...
>The traditional BSD naming scheme as far as I can tell was ... >Our sio driver,
which for many intents and purposes is our reference ... (freebsd-arch) - Re: Service Enum params
... > particularly since you're naming your device with a number. ... A device
interface registered by the driver will have a constant name (some ... >When the application
tries to install another instance of bus driver, ... (microsoft.public.development.device.drivers) - Re: Trouble using JNDI with Tomcat and Oracle
... Make sure that the JAR file with the Oracle driver is in ... Make sure your
context XML file has naming set to "true" (or not set ... (comp.lang.java.databases) - Re: various power management related issues
... Details on the compatibility requirements and available test for each ... >
My question is if this can be OS problem or driver problem? ... > doesnt work anymore
after coming back from hibernate, ... > the modem has its own power cable so its always
turned on even if the box is ... (microsoft.public.development.device.drivers)