[EMAIL PROTECTED] writes:
>
> Michael wrote:
> >I must admit I came rather late into this thread, so I don't
> >understand what you mean by "requiring attachment".
>
> Under CAM, a generic scsi device does not refer to any particular
> piece of hardware. The device is oppened, then attached to a specific
> bus:target:lun combination.
Gross. Doesn't make sense at all. One device per real device. That's
the way it always has been and the way it always should be. Someone
said this was a symbios thing. I checked
ftp://ftp.symbios.com/pub/standards/io/
and I didn't see anything that was obviously about CAM.
Why on earth would you *want* a single device file for all SG devices?
I suppose you could do the same for all SD devices. And all IDE discs.
In fact, why not have a single device file for *all* devices, and just
have a super-duper-monster ioctl() with a 1024 bit device specifier?
Let's take it further and abolish the notion of /dev and instead have
a single open_dev() syscall.
Egads. The mind boggles.
> >> 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 ;-)
>
> Well then :-)
I suspect we're in agreement about CAM (assuming I've got the idea
now).
> >> 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.
>
> Ahh... so there is a device file entry, the inode simply doesn't exist
> yet? What then makes the entry in /dev?
>
> I have the sneaking suspicion I've just missed a simple detail in the
> explanation.
I think the detail you've missed is that you don't need any kind of
inode or device entry in order to attempt an inode lookup. The VFS
calls the devfs lookup() method which checks its internal database of
device entries (registered devices). If it doesn't find one, it calls
kmod and looks again. Does that explain it?
> >> 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.
>
> Hm.
Well, looks like we have something to disagree about. Wouldn't be good
form otherwise ;-)
> I too love the idea of devfs, and want it so show up in the mainline
> (and not as an option either! The next development series should
> have the balls to just make it happen, along with the SG changes
> we're all planning :-); I'm simply sticking to my principles of
> 'proper developemnt procedure'.
Making it non-optional would really get the backs up of those who
don't like the concept. Besides, I don't see any benefit to making it
compulsory anyway. As long as people have the choice, that's all I
care about.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]