Messages in this thread | | | Date | Fri, 18 May 2001 18:02:16 +0200 (CEST) | From | Kai Germaschewski <> | Subject | Re: [kbuild-devel] Re: CML2 design philosophy heads-up |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |