[EMAIL PROTECTED] writes:
>
> (A wholesale round of catching up. The things I miss by going to lunch!)
Ha. You think you've got it hard! Try it when you live in
GMT+10(+1). Get up the next morning and see several iterations of a
debate :-(
> Let's look at it this way. CAM adds an extra layer of indirection
> over a particular /dev entry being hardwired to a particular device.
> The argument is about this layer of indirection. What functionality
> does that layer of indirection get me in return for added
> complexity?
Jargon query: what's "CAM" stand for?
> Answer: none. There is nothing new I can do with the layer of
> indirection that I couldn't do with the old 'hardwired' approach.
> Also in return, my application code becomes more complicated and to
> use any specific device (eg CDROM drive) I have to scan *every
> device on the machine* to find it. The other solution is to
> maintain a registry; another added complexity for no new
> functionality.
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.
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).
> I'm Joe Linux User. When I want to use my cdrom drive, do I think,
> "I'll just plop a disk in old 1:3:0" or do I think "I'll just plop a
> disk in the old CDROM drive"? 99% of uses don't give a rat's ass
> about B:T:L. They want the first cdrom. They want the
> scanner. They want the hard disk. Why should I have to scan the
> whole machine in the common case such that the <1% usage case is
> easier?
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)?
> Richard wrote:
> >Have you heard about devfs? It allows device drivers to register
> >device entries which will automagically appear in /dev. It supports
> >the old-style names "/dev/sg0" as well as the new-style names
> >"/dev/sg/c0b0t0u0" (controller, bus, target, unit).
> >
> >It's not just for SCSI: it's for *all* devices. It's been around for a
> >year now.
>
> *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.
> 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. 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).
> 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?
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).
> I've been warned by a few linux-dev folk here that devfs has caused
> a few flamewars due to opposition; I'm unfamiliar with the arguments
> against it. Would it be possible to summarize presented pros/cons
> or point me to somewhere a discussion may have been archived?
The argument seems to have died off once Linus said that his feeling
was that devfs would go in. Check the kernel archives if you want to
read the arguments.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
