Subject: Re: Refactoring MI devices in GENERIC and friends
To: None <>
From: Quentin Garnier <>
List: tech-kern
Date: 09/08/2007 18:41:39
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 08, 2007 at 03:33:17PM +0200, Joerg Sonnenberger wrote:
> Hi all,
> I would like to see some changes for the way the default configurations
> are handled. We currently have a lot of small variations between GENERIC
> and GENERIC_LAPTOP on i386 and I expect most development e.g. of PCI
> drivers to happen on that platform or at least to be tested on it.
> When new PCI drivers are added, changes are high that *other* platforms
> are even less like to get all entries than GENERIC_LAPTOP to stay in
> sync with GENERIC.
> My suggestion is that all MI drivers for PCI, Cardbus, USB and PCMCIA
> (devices, not necessarily controllers) are collected from i386 and
> amd64's GENERIC kernels and added to
> src/sys/conf/std.{pci,cardbus,usb,pcmcia}. The direct lists of i386 and
> amd64 kernels will refer to those with a possible exception for space
> limited install kernels. Other platforms should be converted by the
> portmaster.
> xtraeme@ volunteered to work on this if we have a consensus. Let's get
> this maintainance nightmare sorted out.

I have three comments about that:

  - I'm not sure maintainance will be any less nightmarish.  While
    doing the "no <instance>" stuff in config(1), I discovered that it
    doesn't bring much.  Commenting out and negating is about the same.

  - Adding a driver which, while MI, is actually rather MD will have
    side effects on other archs.  This is both positive and negative,
    and should be kept in mind.

  - It will be much, much, more difficult for the user to wire down a
    configuration.  IMO, doing this implies that we (the project) rather
    strongly discourage home-grown kernel configurations.

The last point is important to me:  if we do this, we might as well
change the syntax for something much more flexible (like, say, a markup
language rumoured to be extensible, or a subset of it, for which we have
a parser).

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.6 (NetBSD)