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>