[Gllug] SCSI and /dev

[Mike Brodbelt]

On Wed, 2004-03-03 at 21:09, Henrik Morsing wrote:
> > I've never really understood the urge to have a /dev with only valid
> > device nodes in it.
> 
> Makes it a lot easier in my opinion. If you don't know what the device
> name of your new some-card is you're lost.

If you want to know what hardware is on your machine, 2.6 solves that
quite nicely with sysfs, which should be on any 2.6 machine, whatever
it's approach to /dev. Just doing "tree /sys/devices" can be quite
illuminating on a 2.6 machine. as it presents a filesystem
representation of the kernel device structures, so you can see what the
kernel knows about. If it's not mounted, you just need to do:-

mount -t sysfs sysfs /sys

It's always compiled in.

What devfs did do was represent only devices physically present on the
system, and provide notification of device tree changes to userspace,
but with sysfs and udev, who needs that any more? At the same time,
devfs completely failed to address persistent device naming and dynamic
device numbers. So, the most you could get out of it was a few hundred
kilobytes of disk saved, and some hotswap device functionality, but the
kernel duplicates that with hotplug anyway, though that just calls out
to scripts which are often a it hacky.

> > The presence of a few hundred device nodes, which do nothing, and
> > probably consume all of a few K of disk bothers me not at all. That
> > said, I tend to build kernels with the appropriate drivers built in, and
> > not use modules much anyway, so I might just be weird....
> 
> A few hundred?

Few hundred, few thousand, who cares? It's not a performance problem, as
programs don't generally enumerate the directory. Typically, I don't
lose a lot of sleep pondering the output of "ls /dev", and with the cost
of disk space these days, it would have to be *very* large before the
space wastage would worry me.

> And as far as I know the more files you put in a directory the longer it
> takes the system to find one... That is definately a performance hit.

Only if you enumerate the files in the directory. That's a typical
access pattern for many directories, but not for /dev. Doing an open on
/dev/hda (or whatever other device) is not an operation that is affected
by the number of nodes in the directory.

Now udev does interest me, because one of the problems that it's
designed to solve, persistent naming, bugs me personally a lot. I have a
removable media firewire disk, and CF and SD card readers on my machine,
and guessing which is going to be where depending on what I had plugged
in, and what contained media when I booted is something I could do
without. When I put a cartridge in the firewire disk, I typically have
to run rescan-scsi-bus, and then have a guess (or look in messages) at
where it is today before I can mount it. Hardly newbie friendly. 

I'm hoping that udev will fix all that. From what I read, it'll allow me
to set the device ID in a config file, so that it knows to always
allocate the same device node to that disk (or even to a specific
cartridge, AFAICT), and I should just be able to set up a button to
click to mount the disk. That *would* be worth having.

Mike.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug