#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, );
> > > 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, );
> > ioctl(f, SCSI_IOCTL_GET_BUS_NUMBER, );
> >
> > Can you guarantee us that
#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, );
> ioctl(f,
#include hallo.h
* 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,
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 that bit?
open()
#include hallo.h
* 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,
#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
#include hallo.h
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
> 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
#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
> 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
#include hallo.h
* 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
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 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
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 what the
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.
No it can't. The driver has no idea
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.
>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
#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
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
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 vice
#include hallo.h
* 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
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/sg,
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. Then again
28 matches
Mail list logo
