Doug:
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 driver.
Alan Stern
-
To unsubscribe from this lis
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/
URL:
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 th
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 it
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 th
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 requ
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.
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 sto
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:
ftp://ftp
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 conc
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.
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: to the low level transport layer.
It's not a
On Tue, 5 Dec 2006, Joerg Schilling wrote:
> If the number in "sectors" is not a value in sectors but a value in 512 byte
> units, it looks OK.
That's right. This is one of those places where the kernel converts
between the hardware's actual sector size and a fictitious 512-byte sector
size.
>
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: to the low
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 sys
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.
W
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 i
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 onl
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 fi
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
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 dev
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 w
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 re
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
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 char
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 wh
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 _
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
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 guess
o
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
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
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 ca
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
> > > b
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 m
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 descript
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 char
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 h
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()
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. Unfortunat
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
On Fri, 2007-02-09 at 12:57 -0500, Alan Stern wrote:
> > 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 wrot
48 matches
Mail list logo
