All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Douglas Gilbert <dougg@torque.net>
Cc: James.Bottomley@steeleye.com, greg@kroah.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] switch scsi upper driver probing to the driver model
Date: Sat, 17 May 2003 09:13:52 +0200	[thread overview]
Message-ID: <20030517091352.A13403@lst.de> (raw)
In-Reply-To: <3EC5B3B8.9020308@torque.net>; from dougg@torque.net on Sat, May 17, 2003 at 01:59:52PM +1000

On Sat, May 17, 2003 at 01:59:52PM +1000, Douglas Gilbert wrote:
> Is that "_and_" symmetric? That is, can one have the sg
> device in preference to the sd device? If so, how is
> that selected?

You can. In fact there's nothing in this patch that preferes sd over sg
except the existing link order.  A better way to control the driver
matching would be nice but that nothing that should be done in the
scsi code but rather a generic driver model thing.

> Christoph,
> This patch would have some interesting side effects:
>    - no generic interface (apart from SCSI_IOCTL_SEND_COMMAND)
>      for tape devices (st and osst). While the maintainers of
>      st and osst might like this, not all the user apps would :-)

I have some WIP code to make parts of drivers/block/scsi_ioctl.c
working for scsi char drivers.

>    - the extra ioctls that sg defines are either fudged
>      or missing. This might upset programs other than
>      cdrecord; cdparanoia comes to mind

Hmm, what does cdparanoia complain about?  And yes, I think we
need to kill all those return 0 ioctls from the block layer -
they might have helped to bring up the SG_IO code with cdrecord
but they are a really stupid idea long term.

> It was my understanding that the device model has been
> recently modified by Greg KH to cope with the dual nature
> of the interface that sg causes. Evidently similar situations
> occur elsewhere in the kernel.

Greg, any comments on this?  I haven't found any code like that
in drivers/base/ and I can't understand how this is supposed to work..`


  reply	other threads:[~2003-05-17  7:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-16 16:20 [PATCH] switch scsi upper driver probing to the driver model Christoph Hellwig
2003-05-16 23:57 ` Mike Anderson
2003-05-17  2:25   ` Willem Riede
2003-05-17  7:16   ` Christoph Hellwig
2003-05-17  9:17   ` Christoph Hellwig
2003-05-17 16:35     ` Mike Anderson
2003-05-17  9:59   ` Kai Makisara
2003-05-17 15:08     ` Christoph Hellwig
2003-05-17 16:19       ` James Bottomley
2003-05-18  9:35     ` Kai Makisara
2003-05-17  3:59 ` Douglas Gilbert
2003-05-17  7:13   ` Christoph Hellwig [this message]
2003-05-19 19:02     ` Greg KH
2003-05-17  8:32   ` Jens Axboe
2003-05-17 12:52   ` Willem Riede
2003-05-19 21:38 ` Patrick Mansfield

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=20030517091352.A13403@lst.de \
    --to=hch@lst.de \
    --cc=James.Bottomley@steeleye.com \
    --cc=dougg@torque.net \
    --cc=greg@kroah.com \
    --cc=linux-scsi@vger.kernel.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.