#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,
#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_IOCT
#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
#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
#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
#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
#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
#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
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
#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
#include
* Eduard Bloch [Wed, Feb 07 2007, 12:19:53PM]:
> Hello,
>
> I have an ATI Radeon X800 GTO card [1], which works "well"[2] with
> xserver-xorg-video-ati 6.6.3-2 (Debian Sid). However, after upgrading to
> 2.6.20, the console screen is no longer restored afte
Hello,
I have an ATI Radeon X800 GTO card [1], which works "well"[2] with
xserver-xorg-video-ati 6.6.3-2 (Debian Sid). However, after upgrading to
2.6.20, the console screen is no longer restored after switching the
virtual terminal to first console when X has been started once.
Apparently the
Hello,
I have an ATI Radeon X800 GTO card [1], which works well[2] with
xserver-xorg-video-ati 6.6.3-2 (Debian Sid). However, after upgrading to
2.6.20, the console screen is no longer restored after switching the
virtual terminal to first console when X has been started once.
Apparently the
#include hallo.h
* Eduard Bloch [Wed, Feb 07 2007, 12:19:53PM]:
Hello,
I have an ATI Radeon X800 GTO card [1], which works well[2] with
xserver-xorg-video-ati 6.6.3-2 (Debian Sid). However, after upgrading to
2.6.20, the console screen is no longer restored after switching the
virtual
#include
* Bodo Eggert [Sun, Jan 21 2007, 11:40:40AM]:
> Tony Foiani <[EMAIL PROTECTED]> wrote:
> >> "David" == David Schwartz <[EMAIL PROTECTED]> writes:
>
> > Just last night I formatted some new "500GB" drives, and they
> > eventually came back with 465GB as the displayed capacity.
#include hallo.h
* Bodo Eggert [Sun, Jan 21 2007, 11:40:40AM]:
Tony Foiani [EMAIL PROTECTED] wrote:
David == David Schwartz [EMAIL PROTECTED] writes:
Just last night I formatted some new 500GB drives, and they
eventually came back with 465GB as the displayed capacity. Wouldn't
it make
#include
* Jeff V. Merkey [Thu, Dec 14 2006, 12:34:52PM]:
>
> This whole effort is pointless. This is the same kind of crap MICROSOFT
> DOES to create incompatibilities
Just my 0.02€ - one of the things I wonder about is why eg. class*
interfaces has been replaced with something "protected"
#include hallo.h
* Jeff V. Merkey [Thu, Dec 14 2006, 12:34:52PM]:
This whole effort is pointless. This is the same kind of crap MICROSOFT
DOES to create incompatibilities
Just my 0.02€ - one of the things I wonder about is why eg. class*
interfaces has been replaced with something protected
22 matches
Mail list logo
