>Jargon query: what's "CAM" stand for?
Common Access Method.
>As I said previously, devfs gives you both old-style (order dependent)
>as well as new-style (logical names). I can see that you would find it
>simplest to use the old-style names. That's fine: they will continue
>to be supported.
I was addressing Joerg's points, not yours :-)
>However, just as an exercise, how about considering using the
>new-style names? On my system:
>% ls -flF /dev/sr
>total 0
>drwxrwxr-x 1 root root 0 Jan 1 1970 ../
>drwxr-xr-x 1 root root 0 Jan 1 1970 ./
>brw-rw-rw- 1 root root 11, 0 Jan 1 1970 c1b0t6u0
>
>It seems easy enough to scan the appropriate directory for the first
>SCSI CD-ROM. You don't have to worry about checking devices that don't
>exist. Would that suit you? This scheme has the advantage of only
>having to check the contents of /dev/sr, not all of /dev, so it's
>likely to be much faster (if you're worried about speed).
Fine. What I've been arguing for is the generic device file entry
referring to a single device, not requiring attachment.
>I agree that you don't want to scan (including opening inodes and
>checking for ENODEV) all device nodes. But the scheme I proposed above
>avoids that. Or are you concerned about any scanning (i.e. having to
>open directories)?
The problem is that you assumed I was arguing with you, not Joerg :-)
>> *This* I like (and it's sort of like what I was talking about
>> earlier). We both get what we want, and we can put the same generic
>> access interface on each of the devices.
>
>Yep. As I noted above, I think you can even get what you want (or what
>I interpret as what you want) using the new-style names.
Yes, seems so to me.
>> Two questions about devfs unrelated to the ongoing argument: Do the
>> device entries show up when the device module is not loaded? (If
>> not, how do you know the hardware is there? Having to probe by
>> forcing module loads would be a nightmare and only accessible to
>> root).
>
>Device entries only show up when the module is loaded. On a system
>which has kmod running, attempts to lookup an inode which doesn't
>exist will result in a module load attempt.
The problem is of the chicken-and-the-egg variety; how do you open a
file if it doesn't exist?
>Note that directory
>scanning doesn't count as an inode lookup (other than the directory
>itself). Module autoloading is not restricted to root, and seems to
>work quite nicely (it seems quick enough).
Loading the module is fine... the problem is that I can't open the
device file if it isn't there; the module won't load until I open the
file....
>> Second: What is the chance of this becoming mainline? I tend not to
>> code to interfaces that only a few users have patched in.
>
>Pretty good, I think. Last I heard, Linus was considering including it
>sometime in 2.2.x. He first wants to get 2.2.x stable before including
>it. What driver are you writing/maintaining?
Auigh! More brand new stuff in 2.2??
I write cdparanoia and the (yet unreleased) Paranoia IV device library.
See http://www.mit.edu/afs/sipb/user/xiphmont/cdparanoia
>BTW: devfs is entirely optional: it doesn't break the API. The
>intention is that it is drop-in compatible. A large number of drivers
>now have devfs support (this is included in the patch).
A stable release kernel is not the time to introduce something major
like this...
Am I insane? Am I the only one who believes that 'stable' means
'don't randomly fuck with it'?
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
