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