Messages in this thread | | | Date | Tue, 13 Jan 1998 10:54:13 +1100 | From | Richard Gooch <> | Subject | Re: disk naming proposal & devfs (fwd) |
| |
becka@rz.uni-duesseldorf.de writes: > Hi ! > > I am one of the project coordinators of the Linux GGI project, and someone > forwarded me your message. I will comment a bit on your (?) project below, > to give you some more bullets to shoot with ... > > We (the GGI project) would really like this to appear, as there are several > more limitations which will expose themselves, when GGI gets into the kernel. > > The most prominent example is multihead-machines, which have much more > complex requirements regarding input-device arbitration etc. > > > Date: Mon, 12 Jan 1998 21:31:44 +1100 > > From: Richard Gooch <rgooch@atnf.CSIRO.AU> > > To: Larry McVoy <lm@who.net> > > Cc: linux-kernel@vger.rutgers.edu > > Subject: Re: disk naming proposal & devfs > > > > Device File System (devfs) Overview > > Richard Gooch <rgooch@atnf.csiro.au> > > [snip] > > > > /dev management <subsection> > > --------------- > > Because you currently access devices through device nodes, these must > > be created by the system administrator. For standard devices you can > > usually find a MAKEDEV programme which creates all these (hundreds!) > > of nodes. This means that changes in the kernel must be reflected by > > changes in the MAKEDEV programme, or else the system administrator > > creates device nodes by hand. > > The basic problem is that there are two separate databases of > > major and minor numbers. One is in the kernel and one is in /dev (or > > in a MAKEDEV programme, if you want to look at it that way). > > Solving this requires a kernel change. > > Yes. This is very sick and I always hated that. Especially SCSI devices > are not numbered intuitively either, with SANE we had many people trying > to open the wrong /dev/sg?, because they opened the number corresponding > to the SCSI ID ...
With devfs I've adopted a naming scheme for SCSI discs which has host,channel,id,lun,partition, although I also (optionally) support the old sda*, sdb* names. For other SCSI devices I expect the same to be done.
> > /dev as a system administration tool <subsection> > > ------------------------------------ > > Right now /dev contains a list of conceivable devices, most of which I > > don't have. A devfs would only show those devices available on my > > system. This means that listing /dev would be a handy way of checking > > what devices were available. > > Very true. We are currently working on a new console system which is > heavily /proc dependent. And it is very convenient to be just able > to use ls, cat and echo to get information about console configuration > and tweak it. I can see what modules are attached to which console, > what emulation is active for which console, ... > Having the same for devices would be nice ...
Actually, in one of the very few replies Linus made on this devfs thread (back I was still thinking about creating /proc/dev), he pointed out that /proc was already overloaded, and that really the non-process information in /proc would ideally have gone elsewhere.
Perhaps there will be a migration of stuff in /proc to devfs, so you might want to think about placing things in devfs instead of /proc.
> > Readonly root filesystem <subsection> > > ------------------------ > > Having your device nodes on the root filesystem means that you can't > > operate properly with a read-only root filesystem. This is because you > > want to change ownerships and protections of tty devices. > > Not only those. If keeping the traditional scheme, you would want to change > many more devices ... sound is a very prominent example. > > The sound device should normally belong to the current console owner. > Other than that it is either not available (if not world-rw-able), or > a security risk. This has been a known problem for many Unixes ... > > O.K. - one can solve that using some job started on login, but ...
Yes, it's another suid-root programme. The devfs support auto-ownership. This means that a device driver can specify an unopened mode/ownership (i.e. -rw-rw-rw-) but when the device is opened, ownership is changed to the uid/gid of the opening process. When the device is closed, the ownership reverts back to the default.
> In EvStack we have put a considerable effort in moving the permission > problem out of the /dev/ area to avoid these problems. > Our permissions are handled by attaching the devices in a tree-like > structure and events from the devices are redirected as needed ...
Would the devfs auto-ownership system be of use to you?
> > PTY security <subsection> > > ------------ > > Current pseudo-tty (pty) devices are owned by root and read-writable > > by everyone. The user of a pty-pair cannot change > > ownership/protections without being suid-root. > > Yep. VERY sick. > > > Manually creating device nodes <subsection> > > ------------------------------ > > The mknod() method allows you to create an ordinary named pipe in the > > devfs, or you can create a character or block special inode if one > > does not already exist. You may wish to create a character or block > > special inode so that you can set permissions and ownership. Later, if > > a device driver registers an entry with the same name, the > > permissions, ownership and times are retained. This is how you can set > > the protections on a device even before the driver is loaded. Once you > > create an inode it appears in the directory listing. > > Oh - this is nice, yes ... Can the driver change permissions if it requests > that ? I suppose so from your earlier sayings ...
Right now the driver specifies the default permission. That can be changed by manually doing chmod(2). There isn't a facility in devfs to change permissions from within the kernel. Of course you could always call do_chmod()...
> This is very convenient to be able to "glue" devices together, so e.g. > the sound-problem above gets solved ...
Once again: doesn't auto-ownership solve this? Or am I missing something?
> > Installation during the transition phase <section> > > ======================================== > > > > Currently, not all device drivers in the kernel have been modified to > > use devfs. To allow booting of kernels with and without devfs support, > > you will want to copy the contents of /dev to /devfs. Then, remove > > entries in /dev which are now available in devfs and make them > > symbolic links to the entries in /devfs. > > But I did get that right: The major/minor is not strictly necessary > anymore ? Would be good.
That's right. I take whatever major&minor numbers that are given and record them, mostly so that people who <ls -l> a devfs can see the numbers they are familiar with. But that isn't needed to access the device driver. You could provide any major&minor and it would still work. The internal storage is 16 bits each, so you could even supply 65535, although an <ls -l> won't show that value, since the VFS inode only uses 8 bits each. The association is through the devfs namespace, not major&minor numbers.
> > - SCSI discs and generic hard discs > > Note that CONFIG_DEVFS_ONLY is ignored, otherwise you couldn't boot. > > This is because the current root-mounting code only supports a > > major:minor format > > Will the names of the devices change, too ?
Yes and no. I create the old-style sda* names so people can still refer to those, but the new names are like: sd_h0c0i0l0p2 I.e.: host,channel,id,lun,partition.
> People with external SCSI HW would love you for being able to access > > /dev/scsi/disk/IBM08154711/part0 or > /dev/scsi/generic/MUSTEK12000SP or > /dev/scsi/cdrom/SONYCDU1234 > > ... at least as an _alternate_ way.
Perhaps. I think the host,channel,id,lun,partition scheme is *required*, but a config option could also create names with the model number.
> It is more than annoying to have devices shift around, because > another device is turned on at boot or not ... > Some SANE people have already managed to shoot disk-contents, because > a turned off scanner with a low ID caused a disk to have the generic-device > of the scanner ... > > > O.K. - now for the promised bullets : > > Linux-GGI is capable of adding multihead support to Linux. We have systems > running with three displays and are working on ways to attach more than one > keyboard. One developer has reported, he has a true 2-head system using a > normal and a PS/2 keyboard on the mouse connector. > > In theory and with USB devices becoming available, it should be no problem > to have a true 4-headed system driven by a single Linux machine. > > This means 4 times as much tty devices, plus the graphics devices GGI brings, > plus devices for some more things like sound will get virtualized some day ... > > Our EvStack system will add yet another set of devices /dev/event?? which > carry input events for the VTs (well at least we thus save /dev/mouse, > /dev/joystick, /dev/spaceorb, ....).
/dev continues to grow :-/
> For us it would moreover be very helpful, if we could add directory-layers > to the devfs, because it sounds like a good idea to group the tty devices > by the "head" to which they belong. > > I.e. /"dev"/head1/tty?? etc. > > Everything else is unintuitive ... like /dev/head1tty1 ... or some icky > mapping like head=ttynum/64 and using tty1-1024 ...
Right now I don't have sub-directory support. I'm waiting for the dust to settle on the SCSI disc naming argument (i.e. do SCSI discs have their own sub-directory or not?) before taking this any further. I expect that sub-directories will eventually be needed. However, I'd like to avoid a really deep tree, since one of the benefits of devfs is that it becomes realistic to ls /dev and see what hardware you have. A deep directory structure fouls that up again. Perhaps one more level, used to separate major classes of devices, with a /dev/misc for the rest.
> Moreover dynamic changes of the owner and permission would be very nice to > have to make reasonable use of the /dev/graph and /dev/event devices.
That's available now in devfs.
> There are probably quite some more issues, but these are the ones I see > immediately ... > > Go ahead ! This project _is_ worth being followed and included in the kernel.
Thanks.
> P.S.2: Please CC me, when quoting me on linux-kernel (which I am currently > not subscribed to to keep my mailbox from going even over the 100 Mails/day > I currently get ...).
OK.
Regards,
Richard....
| |