From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 17:57:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 523EF1065674 for ; Mon, 21 Jul 2008 17:57:00 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1508FC24 for ; Mon, 21 Jul 2008 17:56:58 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from laptop.deepcore.dk (laptop.deepcore.dk [192.168.0.138]) by deepcore.dk (8.14.2/8.13.8) with ESMTP id m6LHutBf084670; Mon, 21 Jul 2008 19:56:56 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <92DC99EC-22E6-409A-A2A4-A25C57B8A8C3@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Andrey V. Elsukov" In-Reply-To: <827001216661486@webmail53.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 19:56:55 +0200 References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> <827001216661486@webmail53.yandex.ru> X-Mailer: Apple Mail (2.926) Cc: freebsd-current@FreeBSD.ORG, snasonov@bcc.ru Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 17:57:00 -0000 On 21Jul, 2008, at 19:31 , Andrey V. Elsukov wrote: > 21.07.08, 17:52, "S=F8ren Schmidt" : >> 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 =20 >> 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 =20 >> 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) =20= >>> 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, =20= >> 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 =20 >> 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 =20= >> 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 =20 > himself, ok. Well, that was not what I said, but anyways, as long as I stand as =20 maintainer I'd at least try to have a say on how things should be done =20= so maintenance doesn't get more of a nightmare than it already is, nor =20= add work when there is enough already. However, as I already indicated I'm amongst other things using this =20 vacation to think about my continued role here, I've done ATA for 10y, =20= FreeBSD in general for 15y, so forgive me if I sound like an old tired =20= man, I certainly am from time to time :) -S=F8ren > > > --=20 > WBR, Andrey V. Elsukov > -S=F8ren