Messages in this thread | | | Date | Sat, 31 Mar 2007 23:20:02 +0100 | From | Alan Cox <> | Subject | Re: broken device locking, sg vs. sg_io on block devices |
| |
> 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.
> > 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.
> 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.
> IIRC there were similar issues with the SCSI command filtering with > both but I am not sure on that.
SG_IO does command filtering, /dev/sg is intended to be assigned correctly.
> > 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.
> 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 telling the kernel you what you are doing. If you don't then you'll make coasters or even bigger messes.
If you are prepared to fix the apps then I'd suggest fixing them to use fcntl locks with exclusive lock/shared lock according to their need for exclusivity. That would fix some of the HAL problems (open has side effects relocking doesnt), but there are still corner cases with mounted file systems that need handling and I can see those might need some kernel helping hands.
Alan - 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/
| |