Hi Luke
I was wandering whether you could direct me to
a place where I could find the most up to date
patches for libata hotplug support you authored.
Has Jeff Garzik decided to integrate this code
to 2.6 libata ?
Thanks
Ravi
------------------------------
Ravi Wijayaratne
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
On 9/2/05, Ravi Wijayaratne <[email protected]> wrote:
> I was wandering whether you could direct me to
> a place where I could find the most up to date
> patches for libata hotplug support you authored.
>
> Has Jeff Garzik decided to integrate this code
> to 2.6 libata ?
Hey Ravi,
You are on the money in one way; it's September, and I promised
everyone I'd work on it come September. However, this is a loose
timeline; specifically, I'll be available to work on them come the 6th
of this month. So expect some more activity then :)
First of all let me clarify something though; these patches are two parts:
- a libata hotswap infrastructure that allows a driver which
understands and properly handles hotplug interrupts to hotswap drives.
- a specific implementation of this infrastructure in the Promise
SATA150 and SATAII150 line of controllers.
I've been getting quite a few emails offline from people excited with
being able to arbitrarily hotswap all Serial ATA drives, and I should
point out that unless people with the other controllers types (ie.
nForce controllers, Sil controllers, etc.) actually add support for
capturing hotswap interrupts and use the hotswap infrastructure, they
will still not support hotplug. If you send me a controller and the
docs for it, I will add the support and test the b'jesus out of it,
but otherwise only the Promise controllers will have this support.
Here's the current status for all to see:
- I submitted initial patches near the end of July, which were heavily
tested on UP machines and Promise SATA150/SATAII150 Tx4/Tx2 Plus
controllers. They mostly work.
- Jeff suggested some improvements that would make them work better,
and these improvements work better for a general infrastructure (as
opposed to a sata_promise-centric one).
- I sent in patches implementing the improvements on the 1st of
August. They weren't tested at all because I didn't have access to
the hardware at that time, but I wanted some feedback. Those patches
DO NOT WORK, however, they are very close to what I want (I need to
add a workqueue and streamline error-handling a bit more).
- Come the 6th, I'm going to a location where I'll have access to the
controller, as well as UP boxes and an SMP box. So you can expect new
patches, say, by the 10th or 11th that should be well tested and
robust on UP and SMP machines for Jeff's perusal.
So, if you really want hotswap now now now, you'll have to download my
patches and fiddle with them. They're available in the kernel mailing
list archives, if you search for 'hotswap libata', they will come up.
Otherwise, I ask you to be patient for another wek or so and the good
stuff will fall from the sky.
Cheers,
Luke Kosewski
On a happier note, once the infrastructure is accepted, anyone with a
hotswap-unsupported controller and some time on their hands will
easily be able to integrate hotswap in; that is the whole goal of an
infrastructure. So if your controller isn't supported, but you know
something about it (or better yet, you yourself have docs), adding
hotswap support to it should be too hard.
Luke Kosewski
Lukasz Kosewski wrote:
> On a happier note, once the infrastructure is accepted, anyone with a
> hotswap-unsupported controller and some time on their hands will
> easily be able to integrate hotswap in; that is the whole goal of an
> infrastructure. So if your controller isn't supported, but you know
> something about it (or better yet, you yourself have docs), adding
> hotswap support to it should be too hard.
Once the infrastructure is there, I'll probably add support for several
controllers myself. Many controllers don't have an explicit hotplug
interrupt, but rather we must examine the PhyRdy bit in the standard
SError register for details. If the bit's state changes in any way
(including two or more state changes), we (a) check for device presence,
and (b) if device is present, initialize it (SET FEATURES - XFER MODE,
etc.).
Jeff
On Sad, 2005-09-03 at 02:38 -0400, Jeff Garzik wrote:
> controllers myself. Many controllers don't have an explicit hotplug
> interrupt, but rather we must examine the PhyRdy bit in the standard
> SError register for details. If the bit's state changes in any way
> (including two or more state changes), we (a) check for device presence,
> and (b) if device is present, initialize it (SET FEATURES - XFER MODE,
> etc.).
For PATA we may need to reprogram both drives so please be sure that is
allowed for. Also much PATA is "warm swap" not "hot swap" as we have to
perform actions in software prior to the swap.
Alan