Subject: Re: Refactoring MI devices in GENERIC and friends
To: None <tech-kern@netbsd.org>
From: Quentin Garnier <cube@cubidou.net>
List: tech-kern
Date: 09/08/2007 18:41:39
--njUEgrJvs9ryr/H/
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.
>=20
> 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.
>=20
> 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).

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBRuLQw9goQloHrPnoAQL/cwf/esM7xQ3jjwpGEwDPDggkDdyU0ft5NC+q
AqJy7GICrw2BEBRv0Vu0aFcTCZd1mtn5taH8PEkeaPpQKVAn5FyoZIqigNy9bQC1
tZV4GnV4UU5j7QTsAW4M39Xc5zGgjEkojiplFOX9b8PpGrNwvDNk3tAOfepiUl+4
jIkgmSj4w7Gu9iZKZQNC5HaDoqDybtnAV9n8raHrKz7FOp2SID9vSOwbxb7pxy9T
DiR2rea1tk9qD+lPnGiJ2OVOyXdFJjD3cpkgW4lSfJ32c61PxxlD4D0DknnQ5p/+
Wm/Wi6hcqljpt9OG+eGaOz8bZ+fNPLqjrSSChKzuhaWgkGBhlhEf0A==
=TBva
-----END PGP SIGNATURE-----

--njUEgrJvs9ryr/H/--