On Fri, 18 May 2001, Eric S. Raymond wrote:
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets. Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
> we stick to its spec sheet or consider it representative of all derivatives
> (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise. I go for explicitness. If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.
I believe it's important two distinguish between two things here,
auto-configuration and normal configuration.
One should take care to not mix these things up. Of course I don't know
about the specific hardware there, but I believe selecting NVME147 will
give you arch specific code which will cope with general aspects of that
board, but also for derived designs. That makes sense, and no need to
introduce different config symbols at that level.
I'd call CONFIG symbols like that basic, and they should be described by a
ruleset which ensures that building the kernel will actually work, and
that you have a chance that it even runs. (Things like a SCSI driver
requires the SCSI midlayer, etc. which would normally lead to unresolved
symbols or the inability to load the driver module into the running kernel
later).
On the other hand, for some people it would be nice to say I've got the
reference board, build the right kernel. That's okay, but it should be
another option, and rules like that should be in a separate files, so they
don't clutter up the "basic" rulesets.
So, leave the flexibility to people who need, and on top of that you can
have a mechanism which allows easier configuration for people who don't
want to care about the details.
However, more important there would be some option like "build me a kernel
for the hardware I'm currently running on" (and let the user fine tune
afterwards).
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
