#include <hallo.h> * Alan Cox [Sat, Mar 31 2007, 11:20:02PM]: > > But the desktop needs some means to deal with that. AFAICS the only > > feasible way for applications to communicate about device usage policy > > is locking with O_EXCL. Many people do not realize that even read-only > > serial ports and mail both use fcntl file locking , which is much more > flexible.
Again, what does that have to do with the problem at hand? Our problem is not about locking on a single file (no matter which mechanism is used) but the coordination of locks _behind_ the userspace access. Or alternatively reassigning all access to one device file. > > > The kernel does not have sufficient information to handle /dev/sg locking > > > > But the kernel knows already that there is a block device behind it. It > > is displayed in sysfs. It shall "just" reuse the lock mechanism of that > > device, not more and not less. Naturally this "just" definition is > > bendable and that is why I initially asked here. > > This doesn't help. There are legitimate reasons to use /dev/sg on a > device which is active. For most subsystems this actually makes a lot of > sense when doing things like enclosure control. For such uses one can omit the locking. Problem solved. > > The sad thing is, this is just another assumption. At least on Debian > > /dev/sgX belongs to the cdrom group when it's a cdrom device and the > > permissions do just invite to work with it. > > Which means it is privilegded. So? Then let's make /etc/shadow privilegded too: chmod a+r /etc/shadow > > > The desktop user space should really know what it is doing with the CD > > > device if it wants to do things like CD burning. If the serial port > > > people could get this right in 1977 then there is no excuse fo the CD > > > > Serial port? Do we have multiple drivers with multiple interfaces > > accessing the same hardware simultaneously and independently? I don't > > think so. > > getty/modem/uucp/terminal emulator/slip/ppp/.. > > I do think so. Nice try, but where are the different conflicting drivers with different userspace interfaces? Do you have some more flawed comparisons of that kind? > > The use of /dev/sg* is still common practice, its invention predates > > The /dev/sg interface cannot do the locking. If you use /dev/sg you are Again, it doesn't have to. It can pass the locking operations to the related block device driver. The alternative is finding a mapping to the correct block device and act on this one (with O_EXCL or with fcntl, or both). Sysfs looks like a good method to get information for such mapping but unfortunately you (kernel developers) are going to cut even this last path soon (see CONFIG_SYSFS_DEPRECATED and its bold description). Is there any other way I need to know about? Some Voodoo ioctl? Regards, Eduard. -- <alphascorpii> hm, was kann man denn so aus brot machen ... <maxx> knusprige ente (mit etwas geduld) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/