[lkml]   [2007]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

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

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-31 23:19    [W:0.024 / U:1.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site