Re: RFC: Move SG_GET_SCSI_ID from sg to scsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Douglas Gilbert wrote:
Bodo Eggert wrote:
I suggest moving the SG_GET_SCSI_ID ioctl from sg to scsi, since it's generally usefull and the alternative function SCSI_IOCTL_GET_IDLUN is limited in range (in-kernel data types may be larger) and functionality (type, ...).

Bodo,
ioctls, especially new ones, have become very unpopular
in the linux kernel. Whoever implemented the SG_IO ioctl
in the block layer moved just enough other sg ioctls to
fool cdrecord that it was talking to the sg driver. The
SG_GET_SCSI_ID ioctl didn't make the cut, probably because
cdrecord didn't use it.

Mind you, I think it is correct to (try and) move
SG_GET_SCSI_ID to the SCSI subsystem rather than
the block layer. Otherwise we would not be able
to use your proposed ioctl on non-block, sg visible
only devices (e.g. a SCSI enclosure (SES protocol)).

However, I have some questions about that ioctl:

- There is the concept of 8-Byte-LUNs: Are they mapped to integer LUNs?
Should the extra space in the struct sg_scsi_id be used for that?
Or should I abandon the idea and create a new IOCTL instead?

Yes, the SG_GET_SCSI_ID ioctl should allow for 8 byte
LUNs and that is a flaw in the current design. It is
no excuse that the rest of the SCSI subsystem has a
similar shortcoming.

In linux there is also a move away from the host_number,
channel_number, target_identifier and LUN tuple used
traditionally by many Unix SCSI subsystems (most do not
have the second component: channel_number). At least the
LUN is not controversial (as long as it is 8 byte!). The
target_identifier is actually transport dependent (but
could just be a simple enumeration). The host_number is
typically an enumeration over PCI addresses but some
other type of computer buses (e.g. microchannel) could be
involved.

In real SCSI systems that usually maps to card, bus/cable, ID and LUN and allows some correspondence between physical and logical space. Handy to trouble shoot, if you see a lot of errors on the same cable yo have a clue that it may be common cause.

- The original IOCTL will check for sdp->detached. If the moved-to-scsi ioctl is called, the check will be done before chaining from sg, but what
will I need to check if it's called on a non-sg device?

That should not be needed as the open file descriptor
to the SCSI device should be sufficient to keep the
relevant objects alive even if the device was just hot
unplugged.

- Are there any (planned) changes that will conflict with this patch?

There is this thing called sysfs which is advertised
as an ioctl replacement. However if a routine is given
an open device node and you want to find its identity
an ioctl does have some advantages over a procfs followed
by a sysfs trawl. Just like ioctl related structures,
sysfs also changes, frustrating applications built on
it. Sysfs might even change more often than a well designed
ioctl since sysfs is often tightly bound to the driver
software architecture which may change without impacting
interfaces.

Lets see if this post gets a response.

Good to see you still around and posting about the relevant technical details.

--
   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux