lkml.org 
[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: swsusp: don't eat ide disks

On Mon, 4 Nov 2002 benh@kernel.crashing.org wrote:
>
> >Note that "should work" does not necessarily mean "does work". For
> >example, in the IDE world, some of the generic packet command stuff is
> >only understood by ide-cd.c, and the generic IDE layer doesn't necessarily
> >understand it even if you have a disk that speaks ATAPI. I think Jens will
> >fix that wart.
>
> Which is why, IMHO (am I repeating myself ? :) that command has to
> be sent down the queue by the _lowest_ level device driver, that
> is ide-cd, ide-disk, etc...

I would agree with you, but for the fact that:

- I really think we want to have the drivers try to translate SCSI
commands _anyway_.

- that request queue is _damn_important_ in also acting as a
synchronization barrier.

The thing is, many of these commands might well be things user space wants
to do as well, and you have two choices:

- add an ioctl for each kind of command you want to do, and let the
low-level driver do it.

Oh, and btw, we've largely done it this way in the past, and they have
pretty much _all_ gotten the synchronization wrong.

- add one generic ioctl (already done), which pushes a SCSI command down
the pipe, and let the pipe be the synchronization, and cause the switch
to be at run-time.

The thing is, you need to have a case statement for the ioctl, and you
need to have a case statement for the command byte to parse it. And the
SCSI command vs ioctl has a number of advantages:

- you can think of the SCSI command as an ioctl with a standard
numbering and automatic synchronization with the queue.

- a lot of devices can use the raw command as-is, with no case statements
or translation what-so-ever.

Anyway, this is why I'd much rather have higher layers use a standardized
queue packet (a SCSI command) to inform lower-level drivers about special
events, rather than have the lower levels decide on their own command set
and have specialized ways to try to tell them to use that specialized
command some other way (a bdev "ops" structure would probably be the way
we'd go).

So assuming that drivers will accepts commands down the request queue
anyway (because it's the only sane way to push them down and get any kind
of reasonable ordering), then that would make it a waste of time and extra
complexity to _also_ have another interface to push special commands.
Especially as that other interface would end up being almost certainly
broken wrt synchronization (proof: look at the current mess).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2011 Jasper Spaans