On Sat, Sep 08, 2007 at 06:41:39PM +0200, Quentin Garnier wrote:
>   - 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.

Not having to modify 20 kernel configs for random architectures is a
huge improvement.

>   - 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.

I'm talking about things like network devices. I see no valid reason why
a PCI architecture should not have all PCI cards. Most of them can be
obtained in some form as extension module. Even e.g. the Intel wireless
chipsets are present mini PCI cards that are not bound to i386/amd64.

There are some possible exceptions, e.g. HPET makes no sense in such a
file even though it is in dev/ic. I never that all devices must be
present in std.foo, but for 95% or more it is the appropiate place.

>   - 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.

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 more
work than hunting down the rather long list we currently have.

Also note that moving the common devices out makes it easier to
distinuguish GENERIC and GENERIC_LAPTOP for example, so the user has a
much better idea of what the difference is. 

> 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).

I don't think flexibility is really the problem here...

Joerg