linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RFC: hotplug & libata.
@ 2004-10-15 20:16 Andy Warner
  2004-10-15 20:58 ` Bartlomiej Zolnierkiewicz
  0 siblings, 1 reply; 2+ messages in thread
From: Andy Warner @ 2004-10-15 20:16 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-ide@vger.kernel.org

I've spent time over the last 10 days or so working
through hotplug issues with libata and am coming round
to the position that the current __init/probe mechanism
may need some reorganisation for hotplug to work well.

I can currently (mostly) hotplug SATA drives that were
present at __init/probe all day long; but things
are less good for drives which were not present
at __init/probe.

If it's not there at __init/probe time, the groundwork
isn't in place to add devices later without some fairly
nasty & repetitious code. I keep coming back to a model
where the host adapter ports are initialised, then the
initial drive scan & addition is effectively a hot-plug
event (either automatic or forced, depending on hardware
capabilities.)

Unfortunately, I fear that any impending PATA/libata
train-wreck may conflict with this, due to the behaviour
of some (many) of the PATA chipsets out there (e.g.
misbehaving seriously when no active devices are attached
to the bus etc.)

Anyone have thoughts/advice to share on this concept? I think
the re-org may be quite intrusive, and I don't want to waste
cycles on something that "would never work with PATA, because
of blah, blah, blah.."
-- 
andyw@pobox.com

Andy Warner		Voice: (612) 801-8549	Fax: (208) 575-5634

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: RFC: hotplug & libata.
  2004-10-15 20:16 RFC: hotplug & libata Andy Warner
@ 2004-10-15 20:58 ` Bartlomiej Zolnierkiewicz
  0 siblings, 0 replies; 2+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-10-15 20:58 UTC (permalink / raw)
  To: Andy Warner; +Cc: Jeff Garzik, linux-ide@vger.kernel.org

On Fri, 15 Oct 2004 15:16:56 -0500, Andy Warner <andyw@pobox.com> wrote:
> I've spent time over the last 10 days or so working
> through hotplug issues with libata and am coming round
> to the position that the current __init/probe mechanism
> may need some reorganisation for hotplug to work well.
> 
> I can currently (mostly) hotplug SATA drives that were
> present at __init/probe all day long; but things
> are less good for drives which were not present
> at __init/probe.
> 
> If it's not there at __init/probe time, the groundwork
> isn't in place to add devices later without some fairly
> nasty & repetitious code. I keep coming back to a model
> where the host adapter ports are initialised, then the
> initial drive scan & addition is effectively a hot-plug
> event (either automatic or forced, depending on hardware
> capabilities.)

Sounds fine.

> Unfortunately, I fear that any impending PATA/libata
> train-wreck may conflict with this, due to the behaviour
> of some (many) of the PATA chipsets out there (e.g.
> misbehaving seriously when no active devices are attached
> to the bus etc.)

misbehaving?

For the PATA I worry a bit about chipset tuning vs hotplug:
* single PCI config space byte holds settings for all devices etc.
* some hosts don't like when settings for the one port are
  changed while there is IO in flight for the other port

There should be some smart host wide locking for that.

Otherwise I see no major problems for PATA hotplug
(or rather "coldplug") support.

> Anyone have thoughts/advice to share on this concept? I think
> the re-org may be quite intrusive, and I don't want to waste
> cycles on something that "would never work with PATA, because
> of blah, blah, blah.."

Without seeing actual code it is hard to say but I'm an optimist. :)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-10-15 20:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-15 20:16 RFC: hotplug & libata Andy Warner
2004-10-15 20:58 ` Bartlomiej Zolnierkiewicz

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).