From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 17:57:36 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 B75731065699; Sat, 4 Oct 2008 17:57:36 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1E88FC1D; Sat, 4 Oct 2008 17:57:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from s01060021299bf294.vc.shawcable.net ([24.87.45.120] helo=jeeves.bluezbox.com) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1KmBNo-000AlL-81; Sat, 04 Oct 2008 20:57:38 +0300 Message-ID: <48E7AE7D.6020709@bluezbox.com> Date: Sat, 04 Oct 2008 10:57:17 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.16 (X11/20080831) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <48E6D21E.8040808@bluezbox.com> <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> In-Reply-To: <0D306A28-85B2-413D-8A28-862C3C2CE18E@FreeBSD.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Core-Spam-Level: ---- X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Søren 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 moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is 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 more > or less done already, I just need to pull out the right tree here and > that part should be dealt with more or less. Great, I'll wait for results of your work to hit svn. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list 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 17:57:36 -0000 Søren 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 moved > into kernel modules, preferably auto-loadable when a given vendor is > detected, but for starters that could be left out. This is the way to go > for vendor supplied modules as well. I have a least 2 vendors that are > looking into that way of providing support for new chipsets. For a small > kernel you just load the module(s) you need and voila. > > I have VIP in that direction, but its not finished yet, but spiitting up > things is pretty trivial for the most part, except a few gotchas here > and there that will make at least autoloading a wee bit tricky. > > I guess the tedious part is to get all the code moved around into > seperate files, how the actual compile/link/load should be done is 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 more > or less done already, I just need to pull out the right tree 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 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øren > > > On 4Oct, 2008, at 4:17 , Oleksandr Tymoshenko wrote: > >> Hello -arch, >> >> I was playing with p4 mips2 branch catching up with recent developments >> and trying to reduce kernel size for MALTA configuration. At some point >> I ran into ata-chipset.c. This file contains all ATA chipsets 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 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 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 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. >> >> -- >> gonzo >>