From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 02:41:23 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 D79551065694; Sat, 4 Oct 2008 02:41:23 +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 709458FC08; Sat, 4 Oct 2008 02:41:23 +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 1Klwhn-000OfP-5y; Sat, 04 Oct 2008 05:17:16 +0300 Message-ID: <48E6D21E.8040808@bluezbox.com> Date: Fri, 03 Oct 2008 19:17:02 -0700 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.16 (X11/20080831) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 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. [...] 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: sos@freebsd.org Subject: 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 02:41:23 -0000 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