RFC, RFT: AHCI driver reorganization

[Søren Schmidt]

On 21Jul, 2008, at 15:00 , Andrey V. Elsukov wrote:

> Søren Schmidt wrote:
>> This does massive changes to the way AHCI devices are treated, so  
>> it will need testing on all the AHCI platforms currently supported  
>> to make sure nothing breaks. The adding of PM learned me this is a  
>> critical part to touch, ouch :)
>
> Yes, I agree. I think 2 weeks is good time to test :)

Well, this is not a question of time, its a question about getting it  
tested on all possible platforms. This is a major PITA as I'm no  
longer able to have a significant variation of boards/controllers in  
the lab (lack of HW/funds), so its hard to test up front. Posting  
patches wont help much either experience shows, its first when it hits  
the official sources and some time has gone by, that those sytems out  
there will get upgrade and then show the failures.

>
>
>> At any rate, fixing the suspend / resume problems should be dealt  
>> with in a more generic manner, not just for AHCI, by splitting the  
>> work done by the _chipinit and _allocate functions so that just the  
>> chipset specifics can be restored on resume, not the allocations etc.
>
> No, splitting was made before.. It targeted to be more conform to AHCI
> spec. I think after vacation you will have much more time to review.

Much more time ? not likely :)

Anyhow, some of the splitting you have posted before, and I'm not  
convinced that it is the right thing todo, in fact I dont think it is.  
I always lean towards generic code that works on as much HW as  
possible, makes life lots easier in the long run, and I happen to know  
what I'm talking about here, been architecting/developing/maintaining  
ATA as is for 10 fsck'ing years.

Now, trying to hide this under an AHCI specific suspend/resume fix  
wont make it better :)

As I said suspend/resume should be fixed generically so that it helps  
ALL chipsets, that wont get done by random hacks to different  
chipsets, it will lead us right to chaos and kludges all over the  
place, and that scenario will be without yours truely at the ATA helm.

Mind you all the needed code for suspend/resume is already there, its  
"just" a matter of being able to call the different parts in new ways.

>> I'm in doubt as to what makes most sense todo, I'm spare time  
>> limitted still, so progress here is slow, heck my WIP on NCQ  
>> support is still just that and touches the same code parts in ACHI  
>> so they willl get even more behind, oh well...
>> I'm starting to wonder if I should just let it go and leave ATA to  
>> its own faith, and get on with other things...
>
> What about merging some parts of your WIP (which may be published) to
> perforce repository, it may take some time for you, but after that
> some people can help to do some work with your review. ATA is a big
> subsystem and it isn't easy to maintain it alone. I think..

Well, the WIP's I have here cannot be merged in pieces, its all or  
nothing as it changes stuff in many subtle places. Right now I have  
code for NCQ support and for RAID5 support  in the outbound queue, but  
both changes vital parts of the system. I have my own VCS here so  
getting it to something else is just a waste of time that I dont have :)
Some of it still needs clearance before it is let loose in the  
official repos.

Which gets us to the last part about maintenance, yes ATA is a rather  
big subsystem, and its complicated due to all kinds of broken HW out  
there and spec violations etc etc.

If I had the time, I could write a book on how things are put  
together, and how I have architected the subsystem to cope with new  
stuff and feature, but alas that wont happen as my spare time gets  
smaller by the years and so does the donations that could make me use  
business hours for it.

So its all just in my head and on lots of notes around here in the lab  
which makes it difficult to get it across to others. This is really a  
bottleneck, but so far noone has shown the interest or amount of  
knowledge / motivation to get into the matter. I can understand that  
as the workload is immense and there are no returns, only new bug  
reports and requests for support plus the usual whining..

I guess this is a general problem in this kind of project and cannot  
easily be solved..

Now, back to my much needed vacation...

-Søren