[Cc list trimmed]
[EMAIL PROTECTED] writes:
> All that said, I'd still like to get more comments from Richard
> et-al about the "guessing game" problen that devfs creates. I
> *don't* know beforehand what my devices will be named-- I don't even
> know that they're there. Paranoia currently does a long,
> complicated dance with the kernel involving /proc/devices, dev
> directory entries, peeking at the modules compiled into /lib/modules
> and so on to figure out what hardware is on the system without
> hosing the thing into the ground (and potentially crashing it if,
> for example, the Aztech proprietary CD driver tries to load without
> an Aztech CDROM drive actually being there... its autoprobe is
> carnivorous).
OK, I think I wasn't clear enough in a previous message, where I went
on about inode lookups in directories and so on. What happens (for
example with the SCSI CD-ROM driver) is this:
- lookup on /dev/sr which doesn't yet exist will call kmod with
"/dev/sr" which should be aliased to load sr_mod
- sr_mod identifies CD-ROM devices and populates /dev/sr with entries
as appropriate.
A similar thing happens for the IDE CD-ROM driver when you lookup
/dev/ide/cd
So, I think the way you would write your code is to do:
dp = opendir ("/dev/sr");
[/dev/sr will now be populated with the devices you have plugged in]
/* scan entries */
> The whole reason I don't like Joerg's bus:target:lun addressing
> scheme is that I can't go to the hardware that I want; I have to
> probe, probe, probe until I get lucky or decide to give up. (How
> many devices/chains could the machine possibly have? Where do you
> stop looking? SnotFish, my new test box for Paranoia, fills seven
> chains with devices). Devfs now introduces exactly the same problem
> as Joerg's SCG. I can't just say "what are the cdrom drives on my
> system?" without hitting every damed SCSI, parallel port, and
> IDE-like device on the box.
I don't think devfs introduces the same problems, because it groups
things by device class. So a single inode lookup attempt will cause
the appropriate module to be loaded, which in turn populates the
directory.
> OTOH, it would be soooooo easy (believe me I am *drooling* here) if
> I could CD to /dev/sr and see all the CDROM drives on all my SCSI
> chains there indexed by BTL. Then I could go into /dev/sg and see
> everything there by BTL too. Easy direct matching. This doesn't
> address IDE naming and so on (A note to the IDE driver authors-- why
> does the driver hide device type from userspace? Annoying!), but
> just cutting down endless SCSI probing is a big chunk of the battle.
But this *is* what happens with devfs! Look:
[no sr_mod installed]
% ls -F /dev
atmarp= fd@ mem% ptyp2% stdin@ tty3% ttyS1% watchdog%
console% floppy/ null% random% stdout@ tty4% ttyp0% zero%
cpu/ full% port% rd/ tts/ tty5% ttyp1%
cua/ ide/ printers/ root@ tty% tty6% ttyp2%
cua0% initctl| psaux% rtc% tty0% tty7% urandom%
cua1% kmem% ptyp0% sd/ tty1% tty8% vc/
fb/ log= ptyp1% stderr@ tty2% ttyS0% vcc/
% ls -lF /dev/sr
[sr_mod is now loaded]
total 0
brw-rw-rw- 1 root root 11, 0 Jan 1 1970 c1b0t6u0
% ls -F /dev
atmarp= fd@ mem% ptyp2% stderr@ tty2% ttyS0% vcc/
console% floppy/ null% random% stdin@ tty3% ttyS1% watchdog%
cpu/ full% port% rd/ stdout@ tty4% ttyp0% zero%
cua/ ide/ printers/ root@ tts/ tty5% ttyp1%
cua0% initctl| psaux% rtc% tty% tty6% ttyp2%
cua1% kmem% ptyp0% sd/ tty0% tty7% urandom%
fb/ log= ptyp1% sr/ tty1% tty8% vc/
See how /dev/sr now appears in the directory listing of /dev and how
/dev/sr itself is populated?
> This may be looking at the technical problem the wrong way, but
> seriously consider: what would it take to be able to populate /devfs
> accurately and completely from bootup? Without the device
> information always being there (/proc won't help either if the
> module isn't loaded), the greatest benefit of /devfs isn't realized:
> A centralized, accurate, consistent database of devices on the
> machine. Without it, you've solved the duplication problem but at
> the expense of making the interface *much* harder to use (and
> program to).
Unless I'm missing your point, the devfs interface *does* give you an
easy interface even with module autoloading. All you need to do is
scan a few "known" directories for the different types of CD-ROMs and
those directories will show exactly the devices available. Not more
and not less.
BTW: this is a case *for* putting policy in the kernel: you can be
assured that a devfs system will have these names: silly RedHat can't
break things for you. Well, they can, but they'd be insane to create
work for nothing.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
