From: Steven Dake <sdake@mvista.com>
To: andersen@codepoet.org
Cc: greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Advanced TCA SCSI/FC disk hotswap driver for kernel 2.5.44
Date: Thu, 24 Oct 2002 11:12:14 -0700 [thread overview]
Message-ID: <3DB837FE.8080100@mvista.com> (raw)
In-Reply-To: 20021024042838.GA30891@codepoet.org
Erik,
Erik Andersen wrote:
>On Wed Oct 23, 2002 at 04:27:06PM -0700, Steven Dake wrote:
>
>
>>lkml,
>>
>>Attached is an update of the Advanced TCA disk hotswap driver to provide
>>disk hotswap
>>support for the Linux Kernel 2.5.43. Hotswap targets include both SCSI
>>and FibreChannel.
>>
>>
>
>This looks (in parts) similar to the patch I made to make 1394
>hotswapping work correctly.
> http://codepoet.org/scsi_add_remove_single.patch
>The patch is vs 2.4, but you get the idea. Anyway, I think it
>would make more sense for you to fixup proc_scsi_gen_write() to
>make the old hotswap interface (you know the
> echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
> echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
>
>
I wanted to seperate the hotswap functionality from the main scsi code.
I also feel
that hotswap shouldn't be a function of proc. Also, the patch I
supplied supports
fibrechannel hotswap as well. Your patch looks pretty good and I plan
to change
the proc_scsi_gen_write() to use the scsi hotswap commands in hotswap.c.
The
advantage of this technique is that the HBA_ptr doesn't have to be known
(and
this generic code can go in the actual routine instead of the proc
parsing routine).
The final advantage of having seperate comands is less time is spent
passing and
parsing text data. Plus my patch provides usage information for those
that don't
or can't read the source code to understand the interface :)
As far as I'm concerned, I'd be happy to entirely remove the
proc_scsi_gen_write
code, but I think that might confuse some people.
As for the interfaces stomping each other, I've added correct locking to
proc_scsi_gen_write()
to ensure that the host_queue is locked during access so changes to it
cannot occur
during hotswap operations. This keeps a scsi_device entry from being
deleted while
the list is being parsed, resulting in bad magic.
>one) and make it use your new hotswap code. Otherwise the two
>interfaces could easily stomp on each other and hose up the
>kernel when mucking about with scsi host internals.
>
> -Erik
>
>--
>Erik B. Andersen http://codepoet-consulting.com/
>--This message was written using 73% post-consumer electrons--
>
>
>
>
>
prev parent reply other threads:[~2002-10-24 18:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 23:27 [PATCH] Advanced TCA SCSI/FC disk hotswap driver for kernel 2.5.44 Steven Dake
2002-10-24 0:18 ` Greg KH
2002-10-24 0:26 ` Steven Dake
2002-10-24 0:30 ` Greg KH
2002-10-24 16:51 ` Patrick Mochel
2002-10-24 0:27 ` Greg KH
2002-10-24 0:42 ` Christoph Hellwig
2002-10-24 20:04 ` Steven Dake
[not found] ` <20021024042838.GA30891@codepoet.org>
2002-10-24 18:12 ` Steven Dake [this message]
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=3DB837FE.8080100@mvista.com \
--to=sdake@mvista.com \
--cc=andersen@codepoet.org \
--cc=greg@kroah.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).