[5983] in linux-scsi channel archive
Re: WG: AW: cdrecord problems on recent Linux versions
daemon@ATHENA.MIT.EDU (Monty)
Tue Feb 23 16:32:41 1999
To: Richard Gooch <rgooch@atnf.csiro.au>
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: Your message of "Tue, 23 Feb 1999 15:00:59 +1100."
<199902230400.PAA03150@vindaloo.atnf.CSIRO.AU>
Date: Tue, 23 Feb 1999 12:40:11 EST
From: Monty <xiphmont@MIT.EDU>
>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.
*OH*! I thought I'd asked something like that, whoops. Well, gee,
since accessing /dev/sr loads the mod there's not problem at all. The
rest of my mail completely missed what actually went on.
>A similar thing happens for the IDE CD-ROM driver when you lookup
>/dev/ide/cd
Excellent!
>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.
Yes, I'd missed where the module load happened and the fact that
classing was consistent. This handles all my needs and wildest device
identification desires. Granted, I didn't want *that* much :-)
OK, I'm not worried anymore.
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
