On Thu, Oct 24, 2002 at 12:06:33AM +0200, Oliver Neukum wrote: > > > > A model of one simple file to be opened per device _is_ simpler > > > than a number of files to control various settings. > > > Plus, how do you control permissions on that thing ? > > > > The driver controls the initial permissions. I think it will be up to > > userspace to control them after that. > > You'll let a single device's settings have differing permissions > and ownership? > That is ... astonishing and complex. > (I am running out of fitting adjectives. I should look for my dictionary.)
If root, in it's infinite wisdom and power, wants to do such a thing, then hey, I'm not going to question that :) Seriously, this is a userspace issue. The driver can set some initial values that it things is good, but in the end, root can change them to whatever it wants to, nothing new there. > > > Next I'd like to see a lock for attributes and making implementing > > > open mandatory. After that the interfaces should be basically > > > useable, but still I don't think it's for general consumption, ever. > > > > Why should open be mandatory? What do you want to do in open()? > > Proper reference counting and locking. A single read or write interface > is terrible with respect to locking against disconnect. There's a reason > you have to open a file before you read it. Without that the greatest > majority of drivers will get using driverfs wrong. disconnect can not even be prevented with "proper" reference counting and locking. Pat and I have talked a lot about this recently, along with Al Viro and a few other kernel people. This is currently being worked on, and will be solved (hint, my trying to bind a device "state" (present or not) is not what you should do with the reference count, so in a way, the current mess we have in 2.5.44 is my fault, it will be fixed.) Even so, open is not needed to be passed to the driver. Yes, of course you need to do a open() call from userspace, and driverfs will get that and handle the reference counting properly for the device that is attached to that file. The goal is to not have drivers get driverfs (soon to be sysfs) implementation wrong. The current driver interface to it is quite simple, and we want it to stay that way. thanks, greg k-h ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
