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

From: Greg KH (greg_at_kroah.com)
Date: 07/25/04

  • Next message: Greg KH: "Re: SATA disk device naming ?" 
    Date:	Sun, 25 Jul 2004 15:00:26 -0400
To: Doug Maxey <dwm@austin.ibm.com>

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

  • Next message: Greg KH: "Re: SATA disk device naming ?"

    Relevant Pages

    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... this case is useless on ppc... ... completely instead and define it's arch impl. ... ptep_set_dirty_accessedresponsibility to do the TLB flush if ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] fix tulip suspend/resume
      ... then other platforms might require even more. ... > the arch provides a table of state names + function to call for sysfs. ... just merge my patch adding all the new hooks. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 10/14] FRV: Make calibrate_delay() optional
      ... >> this changelog certainly does not apply to the delay loop calibration. ... > I just duplicated the banners from init/main.c and tacked some extra bits on ... > conditional stuff and without having to change every other arch to enable it. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] [request for inclusion] Realtime LSM
      ... >> capability everywhere without potential scheduling DoS. ... Thankfully a buffer underrun is no more fatal for pro audio than a ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 2] Xen core patch : arch_free_page return value
      ... and the compiler will toss it away anyway for all but ... > code that's being bypassed has to be implemented in some form in the arch. ... I wouldn't be merging up any of these patches until we've seen ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)