Re: RFC, RFT: AHCI driver reorganization

From: Søren Schmidt <sos_at_FreeBSD.ORG>
Date: Mon, 21 Jul 2008 19:56:55 +0200
On 21Jul, 2008, at 19:31 , Andrey V. Elsukov wrote:

> 21.07.08, 17:52, "Søren Schmidt" <sos_at_freebsd.org>:
>> 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...
>
> It's sad, I just tried fix problems. But if you want to do it  
> himself, ok.

Well, that was not what I said, but anyways, as long as I stand as  
maintainer I'd at least try to have a say on how things should be done  
so maintenance doesn't get more of a nightmare than it already is, nor  
add work when there is enough already.

However, as I already indicated I'm amongst other things using this  
vacation to think about my continued role here, I've done ATA for 10y,  
FreeBSD in general for 15y, so forgive me if I sound like an old tired  
man, I certainly am from time to time :)

-Søren

>
>
> -- 
> WBR, Andrey V. Elsukov
>

-Søren
Received on Mon Jul 21 2008 - 15:57:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:33 UTC