On Sat, Mar 11, 2000 at 02:38:11PM +0000, Alan Cox wrote:
> > did you enable devfs and forget to edit /etc/inittab to use 'vc/n' instead
> > of 'ttyn' ?
> If that is the case then devfs needs some tweaking
No... That's the way it's designed to work and how it's been
documented... Sigh...
He's got a user space daemon, devfsd, that manages some symlinks
from old names to devfs names, but most of the name space is orthogonal
to the "conventional names". So you either switch to what Richard decided
were more rational names, or you create the symlinks by hand, or you run
his user space daemon. It's in the devfs/README file in the doco directory.
Unfortunately, the devfsd doesn't cover everything (it does cover this,
though). He's got a set of fixed links that it knows about (vc's are in
the list). I haven't looked into it deeply enough to see if it can be
configured for other devices (like the Computone devices) that he didn't
code into it. The Computone devices are not in there, in spite of being
in the devices.txt file:
] 71 char Computone IntelliPort II serial card
] 0 = /dev/ttyF0 IntelliPort II board 0, port 0
] 1 = /dev/ttyF1 IntelliPort II board 0, port 1
] ...
] 63 = /dev/ttyF63 IntelliPort II board 0, port 63
] 64 = /dev/ttyF64 IntelliPort II board 1, port 0
] 65 = /dev/ttyF65 IntelliPort II board 1, port 1
] ...
] 127 = /dev/ttyF127 IntelliPort II board 1, port 63
] 128 = /dev/ttyF128 IntelliPort II board 2, port 0
] 129 = /dev/ttyF129 IntelliPort II board 2, port 1
] ...
] 191 = /dev/ttyF191 IntelliPort II board 2, port 63
] 192 = /dev/ttyF192 IntelliPort II board 3, port 0
] 193 = /dev/ttyF193 IntelliPort II board 3, port 1
] ...
] 255 = /dev/ttyF255 IntelliPort II board 3, port 63
So, contrary to what Richard would lead you to believe in the
README file for devfs, devfsd does NOT have all the links for devices
described in devices.txt.
I'm just getting support for this into the Computone drivers and
trying to get those patches in for 2.4 right now. Got everything in but
one patch from my Computone cohort in crime, Doug, works in the 2.2.14
driver but is causing me a null pointer dereference in an interrupt
driver on 2.3.50. Grrr... It's a bug fix for some signalling problem,
so I guess it will still fit Linus' qualification of bug fixes only. :-)
Convention I've just plugged into the Computone drivers for devfs
(you'll have the patches this weekend, Alan, I swear) is this:
/dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 4
/dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 4
/dev/ttyF[n] -> /dev/ttf/[n] n = 0 - 255
/dev/cuf[n] -> /dev/cuf/[n] n = 0 - 255
> -----
> Linux Filesystem Heirarchy Standard
> 6.1.2
> All devices and special files in /dev should adhere to the Linux Allocated
> Devices document, which is available with the Linux kernel source. It is
> maintained by H. Peter Anvin.
> ------
> Virtual terminals are specifically listed as
> 4 char TTY devices
> 0 = /dev/tty0 Current virtual console
>
> 1 = /dev/tty1 First virtual console
> Thus using any other name places devfs out of the standard. Is there a
> reason for devfs not providing /dev/tty{n} (nothing stops it providing
> /dev/vc/n as well)
Well then why is devfs in there at all then? It's one big glaring
violation of that document unless you run the user space daemon to go with
it. Richard made it very clear that reorganizing /dev was one of his
design goals with devfs.
Here's what the device directory looks like with just devfs (no
effort to create compatibilty symlinks):
[root@wittsend /devfs]# ls
cdroms/ discs/ ip2/ misc/ printers/ random tts/ vcc/
console floppy/ kmem netlink/ ptmx root@ tty zero
cua/ full loop/ null pts/ scsi/ urandom
cuf/ ide/ mem port pty/ ttf/ vc/
[root@wittsend /devfs]
[I have it mounted on a different directory than /dev/ while I test
and develop - cuts back on nasty surprises. :-) ]
Yeah, I'll buy Richard's argument that it's a lot less cluttered
than the conventional names, but to get conformity to the devices.txt
document you are going to have to run the user space daemon or create
the symlinks by hand. He did warn everybody.
I'm of two minds on devfs. First, coming from a Solaris
background where Solaris has done this for years, I don't like it
for largely the same reasons why I though the Solaris convention sucked.
Managing node ownership and permissions using things like "taring up"
the dev directory before shutting down and untarring it during boot-up
just seem like such a kludge. If you don't, you loose any ownerships,
file times, and permissions changes you may have made. If you create
symlinks, you can loose those too, if you don't save them or remake them
everytime. Same thing with directories and non-volatile unix domain sockets.
At least on Solaris, their automagical devices directory is in another
directory (/devices) and virtually everything in /dev/ is a symlink to
something in that directory.
OTOH... It does eliminate configuring the devices for the Computone
boards very VERY nicely, which is a royal pain for conventional device names
and why we had to provide a shar'ed up shell script in our documentation
file plus create some /proc/tty entries.
Damned if you do and damned if you don't, I still haven't made up
my mind on this one.
> Alan
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:19 EST