linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Doug Maxey <dwm@austin.ibm.com>
Cc: Linux IDE Mailing List <linux-ide@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] IDE/ATA/SATA controller hotplug
Date: Tue, 27 Jul 2004 11:31:15 -0400	[thread overview]
Message-ID: <41067543.3090003@pobox.com> (raw)
In-Reply-To: <200407191947.i6JJldK1024910@falcon10.austin.ibm.com>

Doug Maxey wrote:
> Howdy!
> 
>   This note went out originally to a semi-internal list, but after
>   several comments, posting it here...
> 
>   As we chug along here in PPC64 land, we (meaning IBM internal) have
>   been given a requirement to make all devices on our new DLPAR
>   (POWER5 and later) systems be hotplug capable.  This includes ALL
>   PCI devices on the system, even those that are soldered on the
>   motherboard.
> 
>   This raises some interesting issues when dealing with IDE devices.
> 
>   I realize there is considerable work under way (hi Bart :) to clean
>   up the 2.6 trees.  This hotplug work would be another delta on top
>   of that work.
>   The changes could also possibly affect the libata work, as that
>   could also be touched by work on the attached devices themselves.

Why do you think libata is not already hotplug capable, WRT controllers?


>   What I would like is input on the general strategy that should be
>   taken to modify the controller/adapter and device stack to:
> 
>   1) be first class modules, where all controllers/adapters are
>      capable of being loaded and unloaded.  This is directed mostly at
>      IDE/Southbridge controller/adapter devices.

this is already the case in IDE and libata


>   2) extend that support to all child devices; disk, optical,
>      and tape.

this is already the case in IDE and SCSI


>   3) be part of mainline.

this is already the case


>   The items I perceive at the top of the issue list are:
> 
>   - The primary platforms for IDE/ATA devices are x86 based, and
>     certainly do not care about having this capability.

incorrect


>   - Assuming the capability is added, what rework would be acceptable
>     for block devices?

none


>   - Where should this capability go?  Fork a subset of IDE
>     controllers, and put them under the arch specific dir?
>     Or include all devices?

there is nothing arch-specific about this


>   - should we work to the goal of having the capability for all
>     platforms, and all IDE devices?

of course

	Jeff



  parent reply	other threads:[~2004-07-27 15:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-19 19:47 [RFC] IDE/ATA/SATA controller hotplug Doug Maxey
2004-07-25 19:00 ` Greg KH
2004-07-26 19:42   ` Doug Maxey
2004-07-28 22:59     ` Greg KH
2004-07-27 15:31 ` Jeff Garzik [this message]
2004-07-27 20:18   ` Doug Maxey
2004-07-27 21:31     ` J. Ryan Earl
2004-07-27 20:47       ` Doug Maxey
2004-08-11 19:33     ` Jeff Garzik
2004-08-12 11:36       ` Paul Ionescu
2004-07-27 21:14   ` J. Ryan Earl
2004-07-27 20:15     ` Jeff Garzik
2004-07-27 20:20       ` Jeff Garzik

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=41067543.3090003@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=dwm@austin.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --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).