Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jul 2008 21:31:26 +0400
From:      "Andrey V. Elsukov" <bu7cher@yandex.ru>
To:        sos@freebsd.org
Cc:        bu7cher@yandex.ru, snasonov@bcc.ru, freebsd-current@freebsd.org
Subject:   Re: RFC, RFT: AHCI driver reorganization
Message-ID:  <827001216661486@webmail53.yandex.ru>
In-Reply-To: <EF38393C-46AE-486F-B507-7C1AE4D5D8BE@freebsd.org>
References:  <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> <EF38393C-46AE-486F-B507-7C1AE4D5D8BE@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
21.07.08, 17:52, "Søren Schmidt" <sos@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.

-- 
WBR, Andrey V. Elsukov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?827001216661486>