Re: CML2 design philosophy heads-up

[Tom Rini]

On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote:
> Tom Rini <[e-mail]>:
[snip]
> Exactly.  In fact we can be more specific -- the "Macintoshes" in
> question are the old-fashioned NuBus-based 68k toaster boxes, not the
> more recent designs with a PCI bus.  Relevant stuff in the
> Configure.help implies that MAC_SCC and MAC_SCSI enable support for
> the on-board hardware built into those puppies.
>  
> > But Alan's point is a good one.  There are _lots_ of cases you can't get away
> > with things like this, unless you get very fine grained.  In fact, it would
> > be much eaiser to do this seperately from the kernel.  Ie another, 
> > possibly/probably _not_ inkernel config tool which asks what machine you
> > have, picks lots of sane defaults and setups a kernel config for you.  This
> > is _sort of_ what PPC does right now with the large number of 'default 
> > configs' (arch/ppc/configs).
> 
> You're really talking about a different issue here,  autoconfiguration
> rather than static dependencies.  Giacomo Catenazzi is working on that.

Only sort-of.  There are some cases where you can get away with that.  
Probably.  eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
always (right?)  On other arches (someone brought this up before) it could
be PC, it could be something else.  My point is there are only some cases
where you can get away with asking for serial and knowing the driver.  I've
given this some thought before, and at least on PPC, you can at best segment
off some drivers as depending on family X, but family X doesn't mean you
have part Y.  The other thing to keep in mind is I'm sure there's lots of
unintentionally correct bits.  In short, please be very careful when you
change a symbol from a question to a derive.  You're bound to piss off 
someone :)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/