lkml.org 
[lkml]   [2004]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] IDE/ATA/SATA controller hotplug
Date
From

On Tue, 27 Jul 2004 11:31:15 EDT, Jeff Garzik wrote:
>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?

Notice that I did qualify with "possibly". Am not 100% up to speed on
the libata, although it did appear clean, and I am attempting to get
to total understanding. My perception at this time is that the PATA
controllers is where the bulk of the work would be needed. If that is
not true, then great, the kernel is much further along.

Do you have any test cases that are normally run? Assuming that if
these did it exist, they would be more manually than ant kind of
automated.

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

I would have to differ with you here. From conversations and fairly
(2 or 3 months ago) experience, the IDE core is not capable of being
unloaded.

>
>
>> 2) extend that support to all child devices; disk, optical,
>> and tape.
>
>this is already the case in IDE and SCSI

Educational question, what would I be looking for when grokking code
to see this is in place?

>
>
>> 3) be part of mainline.
>
>this is already the case

Yes, the drivers are in the mainline. Just not sure of how many
platforms will have non-pluggable controllers that need to have them
hot-plugged. :-)

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

Ok, please delineate. Working off the assumption that 95+% of the
systems that run Linux are x86 based, and have a single partition for
the system. In other words, no virtual processors, where each is
totally separate from the other.

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

None, in the sense that notification is already present, and no new
mechanism is required, or none in the sense that if a hotplug event
occurs, no one cares?

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

Again, going back to my original premise, that is, which platforms do
you foresee needing this capability? I know that all should have
eventually.

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.186 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site