Date: Mon, 21 Jul 2008 15:52:01 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@freebsd.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: freebsd-current@freebsd.org, Sergey G Nasonov <snasonov@bcc.ru> Subject: Re: RFC, RFT: AHCI driver reorganization Message-ID: <EF38393C-46AE-486F-B507-7C1AE4D5D8BE@freebsd.org> In-Reply-To: <48848887.6020201@yandex.ru> References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21Jul, 2008, at 15:00 , Andrey V. Elsukov wrote: > S=F8ren Schmidt wrote: >> This does massive changes to the way AHCI devices are treated, so =20 >> it will need testing on all the AHCI platforms currently supported =20= >> to make sure nothing breaks. The adding of PM learned me this is a =20= >> 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 =20= tested on all possible platforms. This is a major PITA as I'm no =20 longer able to have a significant variation of boards/controllers in =20 the lab (lack of HW/funds), so its hard to test up front. Posting =20 patches wont help much either experience shows, its first when it hits =20= the official sources and some time has gone by, that those sytems out =20= there will get upgrade and then show the failures. > > >> At any rate, fixing the suspend / resume problems should be dealt =20 >> with in a more generic manner, not just for AHCI, by splitting the =20= >> work done by the _chipinit and _allocate functions so that just the =20= >> 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 =20 convinced that it is the right thing todo, in fact I dont think it is. =20= I always lean towards generic code that works on as much HW as =20 possible, makes life lots easier in the long run, and I happen to know =20= what I'm talking about here, been architecting/developing/maintaining =20= ATA as is for 10 fsck'ing years. Now, trying to hide this under an AHCI specific suspend/resume fix =20 wont make it better :) As I said suspend/resume should be fixed generically so that it helps =20= ALL chipsets, that wont get done by random hacks to different =20 chipsets, it will lead us right to chaos and kludges all over the =20 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 =20= "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 =20 >> limitted still, so progress here is slow, heck my WIP on NCQ =20 >> support is still just that and touches the same code parts in ACHI =20= >> 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 =20= >> 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 =20 nothing as it changes stuff in many subtle places. Right now I have =20 code for NCQ support and for RAID5 support in the outbound queue, but =20= both changes vital parts of the system. I have my own VCS here so =20 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 =20 official repos. Which gets us to the last part about maintenance, yes ATA is a rather =20= big subsystem, and its complicated due to all kinds of broken HW out =20 there and spec violations etc etc. If I had the time, I could write a book on how things are put =20 together, and how I have architected the subsystem to cope with new =20 stuff and feature, but alas that wont happen as my spare time gets =20 smaller by the years and so does the donations that could make me use =20= business hours for it. So its all just in my head and on lots of notes around here in the lab =20= which makes it difficult to get it across to others. This is really a =20= bottleneck, but so far noone has shown the interest or amount of =20 knowledge / motivation to get into the matter. I can understand that =20 as the workload is immense and there are no returns, only new bug =20 reports and requests for support plus the usual whining.. I guess this is a general problem in this kind of project and cannot =20 easily be solved.. Now, back to my much needed vacation... -S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EF38393C-46AE-486F-B507-7C1AE4D5D8BE>