[EMAIL PROTECTED] writes:
> >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 :-)
OK.
> >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 must admit I came rather late into this thread, so I don't
understand what you mean by "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 :-)
Even worse, I'm not quite sure what you're arguing about ;-)
> >> 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?
That's not a problem. The way the VFS works is that any attempt to
refer to an inode (whether or not it exists) causes the lookup()
method for the FS to be called. So if the inode exists, devfs will
just return it to the VFS. If the inode doesn't exist yet, devfs makes
a call to kmod and then looks to see if the inode now exists. If it
does, it's returned to the VFS. If not, that condition is also
returned.
> >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....
See above.
> >> 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??
Devfs is well-tested. What stopped it going into 2.1.x was Linus'
desire to get 2.2 out the door.
> >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'?
Calm down. It's not as bad as you think.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
