#include
* Alan Cox [Wed, Apr 11 2007, 12:31:02PM]:
> > > Can we do following without having side effects:
> > >
> > > open("/dev/sr0",O_EXCL|O_RDWR); /* no matter what it returns */
> > > fcntl(..., F_SETLK); /* no matter what it returns */
> > > ioctl(f, SCSI_IOCTL_GET_IDLUN, &x);
> > > ioctl(f
> > Can we do following without having side effects:
> >
> > open("/dev/sr0",O_EXCL|O_RDWR); /* no matter what it returns */
> > fcntl(..., F_SETLK); /* no matter what it returns */
> > ioctl(f, SCSI_IOCTL_GET_IDLUN, &x);
> > ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, &jo);
> >
> > Can you guarantee us
#include
* Eduard Bloch [Sat, Apr 07 2007, 01:21:31PM]:
> Can we do following without having side effects:
>
> open("/dev/sr0",O_EXCL|O_RDWR); /* no matter what it returns */
> fcntl(..., F_SETLK); /* no matter what it returns */
> ioctl(f, SCSI_IOCTL_GET_IDLUN, &x);
> ioctl(f, SCSI_IOCTL_GET_BU
#include
First, we (me and Thomas Schmidt) are working on a draft for a mandatory
locking scheme which will take care of the most racy situations even
without having a proper in-kernel solution. But you need to exlain some
things, otherwise we cannot rely on your words.
> (open has side effects
> From: Alan Cox
> Newsgroups: gmane.linux.kernel
> Subject: Re: broken device locking, sg vs. sg_io on block devices
> Date: Sun, 1 Apr 2007 01:14:52 +0100
>
[]
>> Again, it doesn't have to. It can pass the locking operations to the
>> related block device driver.
> > > 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.
No it can't. The driver has no idea w
#include
* 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 ma
> 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.
#include
* Alan Cox [Fri, Mar 30 2007, 07:10:38PM]:
> >If there is a simple way to get the mapping between the sg and sr
> >devices that would be great and almost solve the problems, but I
> >cannot discover a such thing in the kernel.
>
> You can go trying to match bus values but we
On Mar 30 2007 16:21, Eduard Bloch wrote:
>>
>> First the hardsware is broken when it can't deal with concurrent requests,
>> I'd try to get a refund for it. Second wodim should never ever use
>> /dev/sg if the sr node is available. And third HAL should stop poking
>> devices all the time. The
>If there is a simple way to get the mapping between the sg and sr
>devices that would be great and almost solve the problems, but I
>cannot discover a such thing in the kernel.
You can go trying to match bus values but we have SG_IO on /dev/sr. This
is an old known problem with /dev/s
#include
* Christoph Hellwig [Fri, Mar 30 2007, 02:43:27PM]:
> > Long story:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
> > https://bugzilla.novell.com/show_bug.cgi?id=226019
> > http://lists.alioth.debian.org/pipermail/debburn-devel/2007-February/000297.html
> > and other error
On Fri, Mar 30, 2007 at 01:17:44PM +0200, Eduard Bloch wrote:
> Hello,
>
> I am talking this issue to LKML now.
>
> Short story: using O_EXCL on /dev/srX alone does not help to prevent
> other process from killing your burn process by just reading the
> /dev/sgX device associated with yours, and
Hello,
I am talking this issue to LKML now.
Short story: using O_EXCL on /dev/srX alone does not help to prevent
other process from killing your burn process by just reading the
/dev/sgX device associated with yours, and vice versa. We have done the
best we could to make safe operation (in contra
14 matches
Mail list logo
