Messages in this thread | | | Date | Sat, 11 Mar 2000 11:25:56 -0500 | From | "Michael H. Warfield" <> | Subject | Re: Linux-2.3.51, and the pre-2.4 series.. |
| |
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/
| |