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.
>> 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 :-)
>> 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.
>> 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.
>> 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.
Hm.
Jens wrote:
>No, I agree with you here. Linus previously talked about shortening
>the development cycle for the kernels and introducing stuff like
>this surely doesn't help.
In fact, stuff like this is the reason the dev cycle has gotten so long.
>I have nothing against devfs - in fact I think it is a great idea.
>But lets focus on getting 2.2.x as stable as possible and putting
>all these great new features in 2.3 instead.
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'.
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
