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....