From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 17:31:31 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 327B71065678; Mon, 21 Jul 2008 17:31:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail53.yandex.ru (webmail53.yandex.ru [77.88.32.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6625D8FC1C; Mon, 21 Jul 2008 17:31:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail53) by mail.yandex.ru id S13189194AbYGURb1 for (+ 1 other); Mon, 21 Jul 2008 21:31:27 +0400 X-Yandex-Spam: 1 Received: from [77.72.136.71] ([77.72.136.71]) by mail.yandex.ru with HTTP; Mon, 21 Jul 2008 21:31:26 +0400 From: "Andrey V. Elsukov" To: sos@freebsd.org In-Reply-To: References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> MIME-Version: 1.0 Message-Id: <827001216661486@webmail53.yandex.ru> Date: Mon, 21 Jul 2008 21:31:26 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: bu7cher@yandex.ru, snasonov@bcc.ru, freebsd-current@freebsd.org 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:31:31 -0000 21.07.08, 17:52, "Søren 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 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