From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 18:31:44 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AF2E106568D for ; Sat, 4 Oct 2008 18:31:44 +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 DFE308FC13 for ; Sat, 4 Oct 2008 18:31:43 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [192.168.0.138] ([192.168.0.138]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id m94IVZbd033251; Sat, 4 Oct 2008 20:31:35 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <8C0B1202-5DF8-45CF-82EA-03367BFABAE7@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: Oleksandr Tymoshenko In-Reply-To: <48E7AE7D.6020709@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 20:31:35 +0200 References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> <48E7AE7D.6020709@bluezbox.com> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Sat, 04 Oct 2008 20:31:35 +0200 (CEST) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Modular ata chipsets data X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 18:31:44 -0000 I found the devel tree with a modulerized ATA subsystem in it, and =20 just upgraded it to the latest greatest from -current. It can be found on http://deepcore.dk/pub/ATA as two files, ata-=20 modules-diff that contains a diff for /sys/conf/files and ata-=20 modules.tgz that is a replacement for /sys/dev/ata. This turns the chipset parts into a module for each vendor, and they =20 are all compiled in as is, however they can be left out on a pr vendor =20= basis (there are a few interdependencies though). I havn't written all the /sys/modules/ata/*/Makefiles that it would =20 take to make it into loadable modules, but thats trivial todo. Now what I'd like to find good generic solutions to is: How to select the proper modules at config/compile time without =20 drowning in "option ATA_BLA_BLA" in the config. How to automagically load the right modules when device probing takes =20= place. It could be loading them all in turn and unloading those that =20 didnt catch anything. I'm not aware of any ways to do this in the =20 kernel, but I've been unattentive for the last many months, so it =20 might have crept in :) Let me know how this works for you, I could very well be tempted to =20 commit it to -current soonish as it makes some things easier to play =20 with. PS: please keep me CC'd still, I dont read arch currently -S=F8ren On 4Oct, 2008, at 19:57 , Oleksandr Tymoshenko wrote: > S=F8ren Schmidt wrote: >> Hi >> (Please keep me CC'd as I do not normally read the list) >> Anyhow, what I would like to see is that the chipset support get =20 >> moved into kernel modules, preferably auto-loadable when a given =20 >> vendor is detected, but for starters that could be left out. This =20 >> is the way to go for vendor supplied modules as well. I have a =20 >> least 2 vendors that are looking into that way of providing support =20= >> for new chipsets. For a small kernel you just load the module(s) =20 >> you need and voila. >> I have VIP in that direction, but its not finished yet, but =20 >> spiitting up things is pretty trivial for the most part, except a =20 >> few gotchas here and there that will make at least autoloading a =20 >> wee bit tricky. >> I guess the tedious part is to get all the code moved around into =20 >> seperate files, how the actual compile/link/load should be done is =20= >> a minor part that can be added when the seperaion is done. >> However, I do have most of that in place in a tree here, so thats =20 >> more or less done already, I just need to pull out the right tree =20 >> here and that part should be dealt with more or less. > Great, I'll wait for results of your work to hit svn. > >> PS: in your patch you suddenly got exclusive Copyright on the Intel =20= >> and AHCI code, that will get you bad karma :) > Ha! I cheated by helping old ladies across the street and got > some extra karma to burn:) As I told - my vim is the one to be blamed, > these copyrights wasn't going to make it into svn commit anyway :) > > >> -S=F8ren >> On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: >>> Hello -arch, >>> >>> I was playing with p4 mips2 branch catching up with recent =20 >>> developments >>> and trying to reduce kernel size for MALTA configuration. At some =20= >>> point >>> I ran into ata-chipset.c. This file contains all ATA chipsets =20 >>> supported >>> by FreeBSD so it was a natural candidate for axing. I hacked small >>> proof-of-concept framework for pluggable ATA chipsets. The idea is =20= >>> to >>> move all vendor-related code to separated modules (.c, not .ko), >>> register each during compile/link-time using ATA_CHIPSET macros >>> (utilizes DATA_SET for this purpose) and provide each chipset with >>> kernel config option. Something like this Warner did to miibus/*phy >>> about two years ago. >>> >>> So far I got only Intel vendor working (tested with Gxemul) and =20 >>> would >>> like to know if it's worth to keep moving in this direction and what >>> possible pitfalls may appear. >>> >>> 90Kb is not that dramatical improvement :), but it's better then =20 >>> nothing >>> and code readability should be better after splitting 180K file into >>> several, IMHO. >>> >>> Patch: http://people.freebsd.org/~gonzo/embedded/modular-ata.diff >>> don't mind copyrights, they're automatically inserted by vim. >>> >>> --=20 >>> gonzo >>> > -S=F8ren