#include <hallo.h>
* Alan Cox [Sat, Mar 31 2007, 11:20:02PM]:
quoted text
> > 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.

quoted text
> > > 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.

quoted text
> > 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

quoted text
> > > 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?

quoted text
> > 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)
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/