From: Douglas Gilbert <dougg@torque.net>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: osst@riede.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] st.c for GET_IDLUN 2.6.6-rc2
Date: Mon, 26 Apr 2004 10:48:50 +1000 [thread overview]
Message-ID: <408C5C72.4020301@torque.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0404251153530.17534@kai.makisara.local>
Kai Makisara wrote:
> On Sun, 25 Apr 2004, Douglas Gilbert wrote:
>
>
>>Kai,
>>A little more testing of st's SG_IO ioctl turned up a
>>small problem.
>>
>>This is the corresponding patch that was applied to the
>>sd driver when it received the block layer SG_IO ioctl.
>>
>>For least surprise of lk 2.4 utilities that use the
>>SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER
>>ioctls (e.g. sg_map) it is better to return the correct
>>values rather than 0.
>>
>
> I definitely agree that those ioctl should not return 0 for SCSI devices.
> However, I think this is a bug in drivers/block/scsi_ioctl.c. Making the
> high-level SCSI drivers parse the ioctl covers up the bug but, IMHO, it is
> not a clean solution. The following two solutions come into my mind:
>
> 1. Fixing drivers/block/scsi_ioctl.c. The simple solution would be to
> return -ENOTTY and then the call would be redirected to the SCSI ioctl
> that does the proper thing. There probably is some reason why this has not
> been done. Other fixes would require knowing if the transport type
> implements the ioctl and this complicates things.
One (!@#$%) reason for putting SG_IO ioctl and friends in the
block layer was to trick cdrecord that it was talking to the
sg device :-) Older versions of cdrecord won't take kindly to
receiving -ENOTTY from the SCSI_IOCTL_GET_IDLUN ioctl.
However always returning 0 may trick cdrecord if there are
2 or more cd/dvd writers (hence my question at the end of my
last post on this thread).
> 2. Reversing the order of calls in st so that scsi_ioctl is called first
> and if it returns -ENOTTY, then scsi_cmd_ioctl is called. This would
> require changing scsi_ioctl to return -ENOTTY for commands not being
> handled but would be othewise a logical solution: first try SCSI specific
> implementation of the ioctl, if it does not exist, then try the block
> layer version (Linux block layer, not Unix block layer ;-).
This solution looks cleaner.
Doug Gilbert
next prev parent reply other threads:[~2004-04-26 0:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-25 8:40 [PATCH] st.c for GET_IDLUN 2.6.6-rc2 Douglas Gilbert
2004-04-25 9:06 ` Kai Makisara
2004-04-26 0:48 ` Douglas Gilbert [this message]
2004-04-26 16:12 ` Kai Makisara
2004-04-28 3:42 ` Douglas Gilbert
2004-04-28 15:21 ` Kai Makisara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=408C5C72.4020301@torque.net \
--to=dougg@torque.net \
--cc=Kai.Makisara@kolumbus.fi \
--cc=linux-scsi@vger.kernel.org \
--cc=osst@riede.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.