[RFC] IDE/ATA/SATA controller hotplug

[RFC] IDE/ATA/SATA controller hotplug

[Doug Maxey]

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.

  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.

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

  3) be part of mainline.

  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.

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

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

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

++doug

Re: [RFC] IDE/ATA/SATA controller hotplug

[Greg KH]

On Mon, Jul 19, 2004 at 02:47:39PM -0500, Doug Maxey wrote:
> 
> Howdy!
> 
>   This note went out originally to a semi-internal list, but after
>   several comments, posting it here...

Unfortunatly, it seems you didn't listen to those comments :(

>   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.
> 
>   2) extend that support to all child devices; disk, optical,
>      and tape.
> 
>   3) be part of mainline.

Great, that all sounds wonderful.

>   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.
> 
>   - Assuming the capability is added, what rework would be acceptable
>     for block devices?

Enough to make it work :)

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

Not in a arch specific dir please.  You all do that too much as it is...

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

Yes.

thanks,

greg k-h

Re: [RFC] IDE/ATA/SATA controller hotplug

[Doug Maxey]

On Sun, 25 Jul 2004 15:00:26 EDT, Greg KH wrote:
>Unfortunatly, it seems you didn't listen to those comments :( 

  Hm.  Which part did I not "listen" to?

++doug

Re: [RFC] IDE/ATA/SATA controller hotplug

[Greg KH]

On Mon, Jul 26, 2004 at 02:42:33PM -0500, Doug Maxey wrote:
> 
> On Sun, 25 Jul 2004 15:00:26 EDT, Greg KH wrote:
> >Unfortunatly, it seems you didn't listen to those comments :( 
> 
>   Hm.  Which part did I not "listen" to?

The fact that I recommend that you do this for all arches.

greg k-h

Re: [RFC] IDE/ATA/SATA controller hotplug

[Jeff Garzik]

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

Re: [RFC] IDE/ATA/SATA controller hotplug

[Doug Maxey]

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

Re: [RFC] IDE/ATA/SATA controller hotplug

[J. Ryan Earl]

Doug Maxey wrote:

>Ok, please delineate.  Working off the assumption that 95+% of the
>systems that run Linux are x86 based
>
Methinks you've forgotten about the embedded market which is mostly 
non-x86 in which there are tens if not hundreds of millions of devices.

-ryan

Re: [RFC] IDE/ATA/SATA controller hotplug

[Doug Maxey]

On Tue, 27 Jul 2004 15:31:04 MDT, "J. Ryan Earl" wrote:
>Doug Maxey wrote:
>
>>Ok, please delineate.  Working off the assumption that 95+% of the
>>systems that run Linux are x86 based
>>
>Methinks you've forgotten about the embedded market which is mostly 
>non-x86 in which there are tens if not hundreds of millions of devices.
>
>-ryan
>

Well, um, ur, you are correct.  Never crossed my mind.  Thank you.

++doug

Re: [RFC] IDE/ATA/SATA controller hotplug

[Jeff Garzik]

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

As long as the low-level driver can be unloaded, that's sufficient for 
hardware- and device-hotplug.


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

Just general refcounting / module support code.


>>>  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 PCI API is a hotplug API.  Whether the underlying controller is 
hotpluggable or not is largely irrelevant to low-level drivers.


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

That's completely irrelevant.  libata and the IDE core work without 
change on x86 and non-x86 systems.


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

All platforms should be considered hotplug.

	Jeff

Re: [RFC] IDE/ATA/SATA controller hotplug

[Paul Ionescu]

On Wed, 11 Aug 2004 15:33:06 -0400, Jeff Garzik wrote:

>> 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.
> 
> As long as the low-level driver can be unloaded, that's sufficient for 
> hardware- and device-hotplug.
> 

Hi Jeff,

On my laptop I have 2 ide buses, ide0 and ide1.
On ide0 I have my hard-drive hda, and on ide1 I have a swappable
cdrom/hard bay as hdc (also I can plug floppy/2nd battery).
I want to be able to hotswap those devices in ide1.
"idectl 1 on/off" from hdparms is broken.
So, I decided to go for modular ide and have the ide module inserted
twice, one time for ide0, and second time for ide1. (of course with 2
different names).
Is this the correct approach ?

I tried to compile IDE as module (kernel 2.6.8-rc4-mm1) in order to have
ide.ko and to be able to insert it with 
insmod ide.ko -o ide0 options="ide1=noprobe"
and
insmod ide.ko -o ide1 options="ide0=noprobe"

Is this supposed to work on a 2.6.x kernel ?
I could not find any ide.ko generated. Only ide-core.ko, ide-generic.ko
and others.

My inspiration was Documentation/ide.txt 

Maybe the docs have to be updated a little bit, but till then, can you
give me some directions on how to proceed further ?

Thanks,
Paul

Re: [RFC] IDE/ATA/SATA controller hotplug

[J. Ryan Earl]

Jeff Garzik wrote:

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

I'm not sure what WRT means, but your last Linux SATA Update did contain:

"Hotplug support
---------------
All SATA is hotplug.

libata does not support hotplug... yet.

The following SATA controllers will never support hotplug:
Intel ICH5, Intel ICH5-R, Intel ICH6 (non-AHCI), Pacific Digital Talon,
Promise SATA SX4."

-ryan

Re: [RFC] IDE/ATA/SATA controller hotplug

[Jeff Garzik]

On Tue, Jul 27, 2004 at 03:14:31PM -0600, J. Ryan Earl wrote:
> Jeff Garzik wrote:
> 
> >Why do you think libata is not already hotplug capable, WRT controllers?
> 
> I'm not sure what WRT means, but your last Linux SATA Update did contain:
> 
> "Hotplug support
> ---------------
> All SATA is hotplug.
> 
> libata does not support hotplug... yet.
> 
> The following SATA controllers will never support hotplug:
> Intel ICH5, Intel ICH5-R, Intel ICH6 (non-AHCI), Pacific Digital Talon,
> Promise SATA SX4."


That refers to SATA devices, not controllers.

	Jeff

Re: [RFC] IDE/ATA/SATA controller hotplug

[Jeff Garzik]

On Tue, Jul 27, 2004 at 04:15:57PM -0400, Jeff Garzik wrote:
> That refers to SATA devices, not controllers.

Or in other words, libata supports PCI bus hotplug (controller<->system
hotplug), but not SATA bus hotplug (device<->controller hotplug).

	Jeff