Re: [address@hidden: Interface for SCSI transactions ?]

[Thomas Schmitt]

Hi,

> That interface isn't complete: the GNU Mach kernel uses linux drivers
> internally, and the scsi_ioctl() function is available there (thus with
> the linuxish interface), but its features have not been propagated to
> the device_get/set_status() user interface yet.

I see.

Googling "hurd device_set_status" found me
  http://www.gnu.org/software/hurd/gnumach-doc/Device-Status.html
which led me to
  http://www.gnu.org/software/hurd/gnumach-doc/Device-Interface.html
Missing is a function by which i can submit a SCSI CDB with eventual
payload data, receive the drive's sense reply, and eventual reply
data.

"scsi_ioctl" brings me to 
  
http://www.koders.com/c/fid51A0FF1F457F60CE69CD6BDDAB2F3CCC0F663DB1.aspx?s=%22John+Rice%22
labeled "GNU/hurd(extremelinux)".
There i read this (linux ?) comment:
   * This interface is depreciated - users should use the scsi generics
   * interface instead, as this is a more flexible approach to performing
   * generic SCSI commands on a device.
   */
  int scsi_ioctl_send_command(Scsi_Device *dev, void *buffer)

(Meanwhile i found gnumach/linux/src/drivers/scsi/scsi_ioctl.c
 on Savannah CVS. Is there a search for functions and other identifiers ?)


> It should be quite
> easy to add it, however, see the device_get/set_status() functions in
> gnumach/linux/dev/glue/block.c

I have some difficulties to squeeze the SCSI transaction model
into device_get_status() as seen on:
  
http://cvs.savannah.gnu.org/viewvc/*checkout*/hurd/gnumach/linux/dev/glue/block.c?revision=1.8.2.10&content-type=text%2Fplain&pathrev=gnumach-1-branch

Is dev_status_t really suitable to control a SCSI transaction and to
record its outcome ?
To me it looks like it controls devices and inquires their state
between transactions.

So i would rather propose a new function with the semantics of SG_IO:
- A drive handle.
- A struct to take parameters and results of the transaction
  (Linux has sg_io_hdr_t).

This could probably be wrapped around the call of scsi_do_cmd() as
happens inside scsi_ioctl_send_command().
Around this call of scsi_do_cmd() i see parameters and reply
data in which a SCSI transaction client would be interested:
  timeout, retries, SCpnt->result, SCpnt->sense_buffer, buf, outlen

(Maybe i should explore my Linux kernel about how SG_IO is implemented.)


--------------------------------------------------------------------------

To further explain my motivation:
Here are some transactions from xorriso inspecting a grub-mkrescue CD.
libburn logs the SCSI commands before submitting them to ioctl(SG_IO)
and it logs the replies which it reads afterwards from sg_io_hdr_t.

  $ xorriso -scsi_log on -dev /dev/sr2 -toc
  GNU xorriso 1.0.6 : RockRidge filesystem manipulator, libburnia project.

  INQUIRY
  12 00 00 00 24 00 
  From drive: 36b
  05 80 00 32 5b 00 00 00 48 4c 2d 44 54 2d 53 54 42 44 44 56
  44 52 57 20 47 47 43 2d 48 32 30 4c 31 2e 30 33 
  ...
  PREVENT/ALLOW MEDIA REMOVAL
  1e 00 00 00 00 00 
  ...
  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = 70 00 02 00 00 00 00 0A 00 00 00 00 04 01 00 00 00 00
  +++ key=2  asc=04h  ascq=01h   (   108 ms)
  ...
  READ TOC/PMA/ATIP
  43 02 02 00 00 00 00 00 30 00
  From drive: 48b
  00 2e 01 01 01 14 00 a0 00 00 00 00 01 00 00 01 14 00 a1 00
  00 00 00 01 00 00 01 14 00 a2 00 00 00 00 00 11 31 01 14 00
  01 00 00 00 00 00 02 00
  ...
  READ(10)
  28 00 00 00 00 10 00 00 10 00
  [reply data not shown because too fat]
  ...

to get this kind of information:

  Drive type   : vendor 'HL-DT-ST' product 'BDDVDRW GGC-H20L' revision '1.03'
  Media current: CD-RW
  Media product: 97m26s65f/79m59s74f , CMC Magnetics Corporation
  Media status : is written , is closed
  Boot record  : El Torito
  Boot catalog : '/boot.catalog'
  Boot image   : '/boot/grub/i386-pc/eltorito.img' , boot_info_table=on
  TOC layout   : Idx ,  sbsector ,       Size , Volume Id
  ISO session  :   1 ,         0 ,      1024s , ISOIMAGE
  Media summary: 1 session, 1174 data blocks, 2348k data,     0 free

Possibly i could achieve this by a more abstract device interface than
generic SCSI.

But when it comes to burning sequential optical media (CD, DVD-R, DVD+R,
BD-R) then i need to send unique MMC commands. The same for formatting
overwriteable media or for controlling Defect Management.
E.g.: A1h BLANK, 5Bh CLOSE TRACK/SESSION,
      55h MODE SELECT with special MMC mode page 5,
      23h READ FORMAT CAPACITIES, AAh WRITE(12) with Streaming Bit set.
     
--------------------------------------------------------------------------

Have a nice day :)

Thomas