Subject: Re: Refactoring MI devices in GENERIC and friends
To: Antti Kantee <firstname.lastname@example.org>
From: Adam Hamsik <email@example.com>
Date: 09/10/2007 10:31:39
-----BEGIN PGP SIGNED MESSAGE-----
On Sep 8, 2007, at 7:46 PM, Antti Kantee wrote:
> On Sat Sep 08 2007 at 19:20:21 +0200, Joerg Sonnenberger wrote:
>>> - It will be much, much, more difficult for the user to wire
>>> down a
>>> configuration. IMO, doing this implies that we (the project)
>>> strongly discourage home-grown kernel configurations.
>> I disagree on this. If you go by the original list, e.g. for a server
>> you would comment out the include for cardbus and PCMCIA. You
>> inline the
>> USB and PCI fragments you are interested in. That is not that much
>> work than hunting down the rather long list we currently have.
> I suggest a tool for flattening the config file, usage e.g.
> config -f GENERIC > MYCONF
I like this idea. We can create generic include files for
isa, cardbus, pcmcia, ipv6, wscons, smb etc.. functions and include
every architecture GENERIC kernel config file. When somebody want to
create own kernel config file "config -f GENERIC > MYCONF" will
generate config file with all options (and without include) .
> That way you could also comment out the inclusion of, say, cardbus
> the config file before flattening it and get a much more trimmed-down
> version without extra goop and a "no cardbus" statement. This
> might be
> at least slightly better for usabilty?
I think that is much more better then now.
> Dunno how much work that is, but I assume negligible for someone who
> knows config(1). Hmm, who around here knows config(1) .... ?-)
>>> 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
>>> language rumoured to be extensible, or a subset of it, for which
>>> we have
>>> a parser).
> IMHO we should discourage home-grown kernel configs, but OTOH we can't
> exactly do that today, tomorrow, or even next week and still have
> everything work. However, would be nice if the project set a policy
> for moving towards this (or moving away from it, if so decided).
Proud NetBSD user.
We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----