Newsgroups: comp.os.linux.announce
From: Theodore Ts'o <tytso@Athena.MIT.EDU>
Subject: The great serial device naming controversy....
Message-ID: <1993May27.123057.16984@klaava.Helsinki.FI>
Date: Thu, 27 May 1993 12:30:57 GMT
Approved: linux-announce@tc.cornell.edu (Lars Wirzenius)

	Greetings, everybody.  Yes, I'm back from Hong Kong..... or
rather, by the time you this message is sent, I will be back from Hong
Kong.  (This note was written over the Pacific Ocean, on United Flight
806 from Hong Kong to San Francisco --- Linux running on Laptops are
truly convenient. :-)  [ And, while I was back last Friday, it's taken
me a couple of days to get over jet-lag and to start catching up on
everything.]

	First of all, I want to thank those of you who sent me messages
of support; especially Arthur Hsieh at Hong Kong Polytechnic, who
offered me the use of an account on his system so that I could get
Internet access back to MIT.  (While it was a slow-grade link, it was
nonetheless extremely useful in downloading backlogged mail from MIT to
my laptop, so I've been able to keep up with Linux developments).  I
also want to thank Peter MacDonald in particular for his decision not to
change the serial naming convention used by the SLS distribution just
yet, and Rick Miller for his understanding and graciousness in
subsequent email messages.

	The upshot of all of this, is that Rick has indicated his
willingness to fix "ps" so that it can accept tty names longer that five
characters, and that the suggested serial naming convention will remain 
the current: /dev/ttyS[0-9], /dev/ttyS[1-9][0-9].

	While this decision has been reached between myself, Rick, and
Peter, it is not necessarily carved in stone.  However, I believe there
are very sound technical and user-interface issues which makes this best
choice of action for the Linux community.  Allow me to explain why:

	First of all, what is the purpose of a "serial device naming
convention"?  It is certainly not to force every single Linux system to
use some set of device names --- this would never work.  Individual
system administrators can and have always been free to choose whichever
names they want to use.  (In fact, I still often use the /dev/ttys??
names on my own personal system, simply because they are easier to type,
some of my config files still depend on them, and I can't imagine EVER
needing more than 48 pty's)

	The real value in having a standardized set of names is for the
new Linux users, who want a plug and play system.  It does not serve
them well if two different distributions of Linux use different serial
names, as that would be highly confusing.  Also, different device names
cause severe heartache because they may be hardcoded into programs, or
shell scripts, or just plain add to the confusion on comp.os.linux when
different people use different conventions. 

	Since changing conventions will result in the same sorts of
confusions and backward compatibility programs as not having a
convention at all, the burden of proof *must* be upon the people
proposing a change in the convention.  There must be a compelling reason
which effects the entire Linux community, or we would be better off
sticking with the old convention.  Hence, in my mind, these are *NOT*
acceptable reasons for wanting to change the naming convention:

	* "ps" only displays two characters after "/dev/tty", so that
	/dev/ttyS10 shows up as "S1".  This is a bug in "ps"; you should
	fix the offending program instead.  Most modern programs allow
	more than five character tty device names; in fact, some systems
	use tty names of the form /dev/tty/serial/1......

	* Being used to the SunOS naming convention..... tough.  If you
	really want, you can use SunOS names on your system.  The
	current system is using the Ultrix naming convention.... the
	old /dev/ttys1 system was using the BSD 4.3 naming convention.
	There are dozens of naming conventions around, and there's no
	way to please everyone.

As to Ian Jackson's suggestion of:

    tty[a-d] for the standard 4 ports,
    tty[e-o][0-f] (tty<port><card>) for multiport cards.
	(I assume the above is a typo, and that he meant tty<card><port>)

In addition to being a gratuitous change, it suffers from the problem
that there is no well-defined mapping between serial device minor
numbers and the names tty[e-o][0-f].  For example, assuming the standard
I/O port and IRQ mappings (which in the latest serial driver are
designed so that users can easily redefine them at boot-time),
the devices /dev/ttyS16 through /dev/ttyS31 could either be:

	* A Usenet Serial II board (only using /dev/ttyS16 through /dev/ttyS19)
	* A Boca 4-port (only using /dev/ttyS16 through /dev/ttyS19)
	* A Boca 8-port (only using /dev/ttyS16 through /dev/ttyS23)
	* A Boca 16-port
	* Two Boca 8-ports
	* Four Boca 4-ports
	* A Usenet Serial II board plus a Boca 4-port (only using 8 ports)

Given the explosion of combinatorical possibilities, any standard naming
scheme which tries to encode which card a particular port is on is
doomed to fail.  The serial driver doesn't really care which ports are
shared by which card, and trying to make the naming system care is
impossible.  If you really want to do this, then you can specially
assign appropriate names on your system.  But for the purposes of a
standard naming convention, it is a requirement that /dev/ttyS12 has the
same major, minor device number as /dev/ttyS12 on some other system
following the same naming convention.

So, what is the bottom line?  It is my suggestion that people
distributing Linix distributions use the following (unchanged) serial
naming convention:

	/dev/ttyS0 major 4, minor 64
	/dev/ttyS1 major 4, minor 65
	....
	/dev/ttyS9 major 4, minor 73
	/dev/ttyS10 major 4, minor 74
	...

	/dev/cua0 major 5, minor 64
	/dev/cua0 major 5, minor 65
	...
	/dev/cua9 major 5, minor 73
	/dev/cua10 major 5, minor 74
	...

I also suggest that for most systems, which only have one modem,
/dev/modem be a symlink to the appropriate /dev/cuaXX device.  This way
people can have .kermrc files that can say things like "set line
/dev/modem".

I hope this settles the issue; but if there are some very good reasons
for change, using the standards outlined above, I'd be glad to hear
them.

						- Ted
