mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Steven Dake <sdake@mvista.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] Advanced TCA SCSI Disk Hotswap
Date: Thu, 24 Oct 2002 18:42:16 -0500	[thread overview]
Message-ID: <200210242342.g9ONgGT04819@localhost.localdomain> (raw)
In-Reply-To: Message from Steven Dake <sdake@mvista.com>  of "Thu, 24 Oct 2002 13:45:48 PDT." <3DB85BFC.2080009@mvista.com>

> The locking most definately needs to be added to the kernel.  I'm
> surprised the original patch didn't contain any locking, but then
> again, my first patch didn't  either:) 

When I first read the SCSI code many years ago, I found surprise wasn't 
adequate and I was forced to resort to astonishment.  It's being cleaned up 
slowly.

Originally hot removal/insertion was the exception, so nobody tripped over the 
locking issue.  Now it's fast becoming the rule.

> This may be true, but most systems will only have at most 4-5 devices.
> 
>  Theres only so much room on PCI for FC devices :) 

I have to think about other SCSI systems as well.  Some IBM beasties have > 
256 PCI slots.  Infiniband is threatening direct bus-fibre attachment.

> In Advanced TCA (what spawned this work) a button is pressed to
> indicate  hotswap removal which makes for easy detection of hotswap
> events.  This is why there are  kernel interfaces for removal and
> insertion (so a kernel driver can be written to detect  the button
> press and remove the devices from the os data structures and then
> light a blue  led indicating safe for removal). 

OK, I understand what's going on now.  It's no different from those hotplug 
PCI busses where you press the button and a second or so later the LED goes 
out and you can remove the card.  10ms sounds rather a short maximum time for 
a technician to wait for a light to go out....I suppose Telco technicians are 
rather impatient.

I really think you need to lengthen this interval.  The kernel is moving 
towards this type of hotplug infrastructure which you can easily leverage (or 
even help build), but it's definitely going to be mainly in user space.

James




  parent reply	other threads:[~2002-10-24 23:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200210242002.g9OK27W03864@localhost.localdomain>
2002-10-24 20:45 ` Steven Dake
2002-10-24 21:05   ` Randy.Dunlap
2002-10-24 21:48     ` Steven Dake
2002-10-24 23:00     ` Scott Murray
2002-10-24 23:22       ` Greg KH
2002-10-24 23:48         ` Steven Dake
2002-10-25  0:20           ` Jeff Garzik
2002-10-25 10:04           ` Alan Cox
2002-10-25  0:18         ` Scott Murray
2002-10-24 23:42   ` James Bottomley [this message]
2002-10-24 23:52     ` Jeff Garzik
2002-10-27 15:08       ` Rob Landley
2002-10-27 20:25         ` Randy.Dunlap

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=200210242342.g9ONgGT04819@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sdake@mvista.com \
    /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

Powered by JetHome