Hi,
it's 2 monts that we did discuss this problem.
Has the solution integrated into the Linux kernel?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
On Fri, 9 Feb 2007, Joerg Schilling wrote:
Hi,
it's 2 monts that we did discuss this problem.
Has the solution integrated into the Linux kernel?
Jörg
Not yet. Despited repeated inquiries, I still haven't heard anything back
from James regarding the patch that he wrote.
James, if you
On Mon, 8 Jan 2007, James Bottomley wrote:
On Mon, 2007-01-08 at 11:19 -0500, Alan Stern wrote:
Back in December you wrote a patch to expose the queue ioctls, and sent it
(off-list) to Jens Axboe and to me. Jens spproved it, but then it
disappeared and was never applied. Unfortunately I
On Wed, 6 Dec 2006, James Bottomley wrote:
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set,
and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
it won't work with sg, which uses character
On Mon, 2007-01-08 at 11:19 -0500, Alan Stern wrote:
Back in December you wrote a patch to expose the queue ioctls, and sent it
(off-list) to Jens Axboe and to me. Jens spproved it, but then it
disappeared and was never applied. Unfortunately I have lost my copy of
it.
If you still have
On Mon, Jan 08 2007, Alan Stern wrote:
On Wed, 6 Dec 2006, James Bottomley wrote:
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set,
and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue().
So
Alan Stern [EMAIL PROTECTED] wrote:
I will. If everything goes well then BLKSECTGET will be made to work with
the SCSI-Generic interface as well as with the usual block device files,
so you'll be able to use it with any file descriptor for a CD or DVD
drive.
Coud you please inform me if
On Fri, 8 Dec 2006, Joerg Schilling wrote:
Alan Stern [EMAIL PROTECTED] wrote:
I will. If everything goes well then BLKSECTGET will be made to work with
the SCSI-Generic interface as well as with the usual block device files,
so you'll be able to use it with any file descriptor for a
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 6 Dec 2006, Mike Christie wrote:
Alternatively, if we do start not checking values like max sectors and
send requests down to the drivers, the block layer mapping functions can
be modified to not check certain values and LLDs/scsi-ml can return
On Thu, 7 Dec 2006, Joerg Schilling wrote:
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 6 Dec 2006, Mike Christie wrote:
Alternatively, if we do start not checking values like max sectors and
send requests down to the drivers, the block layer mapping functions can
be modified to
On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
But how did he get the file descriptor? He opened a device name, which
could have been used to get the sysfs file.
The device name was probably something like /dev/sg0. This doesn't easily
permit one to find the corresponding sysfs
On Wed, 6 Dec 2006, James Bottomley wrote:
Realistically, no-one makes SCSI CDs or DVDs any more ... I know, I've
tried to get some for some of my older boxes. Most of them nowadays are
IDE attachments, which don't have a /dev/sg node. So /dev/sg is really
the legacy mode for burning.
On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
So only the legacy sg character-device files need attention, which
means
that only the part of the patch affecting sg.c is necessary. The new
SG_GET_MAX_TRANSFER_LENGTH ioctl can remain unimplemented by the
block
layer -- just as
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
Well, accept the patch if it works.
It's not about work/not work: it's about correctness.
And in case that you don't like it, make sure that the _parameter_ is
moved to where it belongs:
James Bottomley [EMAIL PROTECTED] wrote:
All CD/DVD burners are block devices, which is the problem set under
discussion.
Please keep in mind: all CD/DVD burners are SCSI devices.
You cannot write or even retrieve special information without SCSI.
Jörg
--
EMail:[EMAIL PROTECTED] (home)
Alan Stern [EMAIL PROTECTED] wrote:
It turns out that for block device files we don't need to change anything.
The BLKSECTGET ioctl already does almost exactly what we want:
int n;
if (ioctl(fd, BLKSECTGET, n) == 0)
max_transfer_size = n * 512;
So only the
On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
Please keep in mind: all CD/DVD burners are SCSI devices.
This is probably semantics, but nowadays, SCSI means SPI (or parallel
SCSI). I think you're trying to say that they're all devices that obey
the MMC standard? Which is true, but
James Bottomley wrote:
On Wed, 2006-12-06 at 11:32 -0500, Alan Stern wrote:
But how did he get the file descriptor? He opened a device name, which
could have been used to get the sysfs file.
The device name was probably something like /dev/sg0. This doesn't easily
permit one to find the
James Bottomley wrote:
On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
Please keep in mind: all CD/DVD burners are SCSI devices.
This is probably semantics, but nowadays, SCSI means SPI (or parallel
SCSI). I think you're trying to say that they're all devices that obey
the MMC
James Bottomley [EMAIL PROTECTED] wrote:
On Wed, 2006-12-06 at 18:49 +0100, Joerg Schilling wrote:
Please keep in mind: all CD/DVD burners are SCSI devices.
This is probably semantics, but nowadays, SCSI means SPI (or parallel
SCSI). I think you're trying to say that they're all devices
On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
SPI is dead. Get used to it. SCSI has not meant SPI for
years. We should be in the business of disabusing people
of that idea, not reinforcing it.
I don't believe I said anything in favour of or against SPI.
I think you'll find the
On Wed, 6 Dec 2006, James Bottomley wrote:
On Wed, 2006-12-06 at 12:21 -0500, Alan Stern wrote:
So only the legacy sg character-device files need attention, which
means
that only the part of the patch affecting sg.c is necessary. The new
SG_GET_MAX_TRANSFER_LENGTH ioctl can remain
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set,
and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
it won't work with sg, which uses character device nodes.
Well, even sg has the queue ...
James Bottomley wrote:
On Wed, 2006-12-06 at 13:38 -0500, Douglas Gilbert wrote:
SPI is dead. Get used to it. SCSI has not meant SPI for
years. We should be in the business of disabusing people
of that idea, not reinforcing it.
I don't believe I said anything in favour of or against SPI.
On Wed, 6 Dec 2006, James Bottomley wrote:
On Wed, 2006-12-06 at 13:58 -0500, Alan Stern wrote:
I'd love to do that -- but blkdev_ioctl() wants inode-i_bdev to be set,
and blkdev_locked_ioctl() uses it as the argument to bdev_get_queue(). So
it won't work with sg, which uses character
Douglas Gilbert wrote:
James Bottomley wrote:
On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
Well, accept the patch if it works.
It's not about work/not work: it's about correctness.
And in case that you don't like it, make sure that the _parameter_ is
moved to where it belongs:
On Wed, 6 Dec 2006, Mike Christie wrote:
Alternatively, if we do start not checking values like max sectors and
send requests down to the drivers, the block layer mapping functions can
be modified to not check certain values and LLDs/scsi-ml can return
these BLKERR values all the way up to
Mike Christie wrote:
Douglas Gilbert wrote:
James Bottomley wrote:
On Wed, 2006-12-06 at 00:14 +0100, Joerg Schilling wrote:
Well, accept the patch if it works.
It's not about work/not work: it's about correctness.
And in case that you don't like it, make sure that the _parameter_ is
On Wednesday 06 December 2006 16:50, Mike Christie wrote:
For iscsi, we could negotiate a value like MaxBurstLength which says
don't send commands with a payload larger than that size. I would guess
other transports have something similar. We have to check or make sure
...
Oh yeah the
On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
On Wednesday 06 December 2006 16:50, Mike Christie wrote:
For iscsi, we could negotiate a value like MaxBurstLength which says
don't send commands with a payload larger than that size. I would guess
other transports have something
Mike Christie wrote:
Jeremy Linton wrote:
On Wednesday 06 December 2006 17:42, Jeremy Linton wrote:
On Wednesday 06 December 2006 16:50, Mike Christie wrote:
For iscsi, we could negotiate a value like MaxBurstLength which says
don't send commands with a payload larger than that size. I would
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap: Joerg Schilling needs to be able to retrieve the max_sectors
value for a SCSI device's request queue. Doing
On Tue, 2006-12-05 at 15:52 -0500, Alan Stern wrote:
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap: Joerg Schilling needs to be able to retrieve the
Alan Stern wrote:
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap: Joerg Schilling needs to be able to retrieve the max_sectors
value for a SCSI device's
Alan Stern [EMAIL PROTECTED] wrote:
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Thank you, this is a more convenient way of having a discussion.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
To recap:
James Bottomley [EMAIL PROTECTED] wrote:
Is the patch below acceptable?
Really, no. The parameter you're fishing for is a block parameter, not
a SCSI parameter ... it should really be a block ioctl if we have to
have an ioctl at all.
I am afraid, you seem to missunderstand things.
This
On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
I am afraid, you seem to missunderstand things.
This parameter is not related to something you may call block layer, it is
rather related to the low level SCSI transport. If the value is stored in a
higher layer, it is not stored in
Alan Stern [EMAIL PROTECTED] wrote:
I decided to do this by email instead of bugzilla so that it would be
visible to everyone on the linux-scsi mailing list.
Re: http://bugzilla.kernel.org/show_bug.cgi?id=7026
I just put out preliminary support for this ioctl.
Please check:
Douglas Gilbert [EMAIL PROTECTED] wrote:
BTW Joerg: SG_SET_RESERVED_SIZE simply makes it extremely
unlikely that the sg driver will not be able to fetch
enough memory from the kernel to move data associated with
a SCSI command. The block layer SG_IO just fudges that.
While a major concern in
James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2006-12-05 at 23:46 +0100, Joerg Schilling wrote:
I am afraid, you seem to missunderstand things.
This parameter is not related to something you may call block layer, it
is
rather related to the low level SCSI transport. If the value
On Mon, 2006-12-04 at 15:11 -0500, Alan Stern wrote:
Can you please take a look at this entry in Bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=7026
The important part starts at Comment 21; in particular the last two
comments from Joerg Schilling and me are relevant to the SG
41 matches
Mail list logo
