All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: "Ely, Paul" <Paul.Ely@Emulex.Com>
Cc: 'Christoph Hellwig' <hch@infradead.org>,
	"Smart, James" <James.Smart@Emulex.Com>,
	Linux SCSI Reflector <linux-scsi@vger.kernel.org>
Subject: RE: suspending I/Os to a device
Date: 28 Jul 2004 10:41:55 -0400	[thread overview]
Message-ID: <1091025718.2072.75.camel@mulgrave> (raw)
In-Reply-To: <3356669BBE90C448AD4645C843E2BF28025AB7AA@xbl.ma.emulex.com>

On Mon, 2004-07-26 at 15:11, Ely, Paul wrote: 
> I think the sysfs implementation for the nodevice_tmo
> attribute needs to be rethought.
> 
> The nodevice_tmo really is a scsi device-specific attribute
> and although it could apply to Fibre Channel, iSCSI,
> or usb-connected storage, defining it in the scsi_transport_fc.c/h
> files doesn't really work since:
> 	1. The midlayer doesn't interface with the transport
> 	   interface directly.
> 	2. Each transport type would need to replicate the
> 	   transport_fc at least for the nodevice_tmo.
> 	3. Implementing this is messy.

Surely not if the implementation is done in scsi_lib.c?  The idea being
that you provide the storage area in the transport attributes but the
routines for handling it are all in scsi_lib so any transport that needs
it can hook in easily and transports that don't care don't bother and
don't waste the storage space.

This concept applies to a few other attributes we might do, which is why
I'm interested in seeing how it could work.

> I am working on a modification to move the nodevice_timeout
> value and timeout error handler into the scsi_device structure
> since it really is a scsi device attribute that needs to be
> managed by the midlayer.

It's a device attribute, but since it's use should be optional I'm not
convinced it needs to be in every SCSI device.

James



  reply	other threads:[~2004-07-28 14:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-26 19:11 suspending I/Os to a device Ely, Paul
2004-07-28 14:41 ` James Bottomley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-06 19:36 Paul.Ely
2004-08-02 21:22 Ely, Paul
2004-07-28 16:19 Ely, Paul
2004-07-23 13:26 Ely, Paul
2004-07-22 20:16 Ely, Paul
2004-07-23  4:36 ` Nathan Bryant
2004-07-19 20:04 Ely, Paul
2004-07-12 20:53 Ely, Paul
2004-07-17 12:24 ` Christoph Hellwig
2004-05-05 19:00 Smart, James
2004-04-26 17:12 Infante, Jon
2004-04-26 21:26 ` 'Patrick Mansfield'
2004-04-23 22:12 Infante, Jon
2004-04-23 23:28 ` James Bottomley
2004-04-26 16:40   ` Patrick Mansfield
2004-04-23 16:28 Ely, Paul
2004-04-23 15:59 Infante, Jon

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=1091025718.2072.75.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=James.Smart@Emulex.Com \
    --cc=Paul.Ely@Emulex.Com \
    --cc=hch@infradead.org \
    --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.