Re: SG_IO ioctl (was: mode sense blacklist how)

[Pat LaVarre <p.lavarre@ieee.org>]

Doug G:

> The SCSI command timeout should bring things back but often at the
> expense of a bus reset (on SPI) which can have some nasty side effects
> (e.g. if your root file system is on a disk on the same SPI bus).

Aye.  From reset-issued-Before-next-command I get nasty side effects in
SCSI over IDE (aka ATAPI), SCSI over USB, SCSI over FireWire ...

> > more prominent device names like /dev/hdd and /dev/scd0
> > in place of less prominent /dev/sg$n names ...
> ...
> trade-off ...
> Pros: ... - ... - ...
> Cons: ... - ... - ... - ... - ... - ...
> more "cons" will come to light ...
> probably enough ... to give the cdrecord author pause for thought.

Wow.  Prompt, incisive.  Thank you offline to this doc I will link folk.

http://marc.theaimsgroup.com/?l=linux-scsi&m=106937826522932

List:     linux-scsi
Subject:  SG_IO ioctl (was: mode sense blacklist how)
Date:     2003-11-21 1:17:16
 
> > Sorry I'm too much of a kernelnewbie to guess confidently the full
> > implications of "not interruptible".  Does "not interruptible" mean
> > timeouts don't work, or does "not interruptible" mean that only timeouts
> > work, or does "not interruptible" mean that only timeouts and resets but
> > not SIGINT of the calling process works ...
> 
> "Linux Kernel Development" Robert Love ISBN 0-672-32512-8 covers
> lk 2.6 pretty well including these issues. [Note in passing: the
> book makes no mention of the SCSI or ATA subsystems or aio:-(]

Thanks for the link, I will look again, I should manage to click thru to
hardcopies of same or similar title within twenty-four hours.

Perhaps I should have mentioned I am only a Linux kernelnewbie, not a
nano"kernel newbie", so I've found a few much-linked Linux books
frustratingly waste many words telling me again what I already know.

> "not interruptible" in this context means that signals (e.g.
> control-C from the keyboard or kill-9) have no effect while
> waiting for the SCSI response.

My Terminal Ctrl+C becomes SIGINT and kills my main user thread and user
process but doesn't affect the kernel thread serving me?  Ever?  Or only
no effect til that thread tries to return?

> ** ... if sg (plus st + osst) had sysfs visibility ...

This I'm too new to grok but I see others answering already.

Pat LaVarre