Jeff Garzik <jgarzik@mandrakesoft.com>:
> IMNSHO this attitude is wrong. If building the kernel is tough for
> newbies, make a userland utility with all these policy questions and
> features. We are talking about an interface on the KERNEL DEVELOPER
> side of the line.
We'll have to disagree on this. I am just as firmly of the opinion that
a well-designed tool can serve both populations well.
> I am all for making the kernel build and config process more flexible,
> but I am NOT at all for "dumbing down" the interface just so to make it
> easier for newbies to build a kernel.
Fine. You choose EXPERT or WIZARD on the policy menu, then.
> huh? compared to what ? It is simple to read, simple to modify. The
> major nasty issue right now is dependencies not readability.
It's pretty nasty -- mec himself, the CML1 maintainer, thinks so and
strongly encouraged me to shoot CML1 through the head if I could
possibly manage it. Perhaps you're too close to it to see how ugly it is.
> This definitely needs to be cleaned up, since some of the arch config.in
> code exists solely to work around problems which [presumeably] don't
> exist in yournew system.
>
> However I think that getting rid of the top-level arch files entirely
> will make for administrative headaches. Make sure you communicate
> thoroughly with the port maintainers on this one...
I'm aware that the One Big Tree design will entail some coordination
problems among the port maintainers. I'm pretty sure that, on net,
they'll be less than the friction costs of the present mess.
> You drop the CONFIG_xxx prefix? That's not something you do lightly,
> nor is it something you toss off as an aside. CONFIG_xxx is an
> important namespace convention and exists in a lot of existing kernel
> code.
You misunderstand. CML2 generates the CONFIG_ prefix into the config
files; I'm not changing the actual config-symbol namespace. it just
doesn't use the prefix in the ruleset declarations. Without it, the
symbols I'm requesting changes to look like malformed numbers.
> > Also, I had to change the KEYBOARD and MOUSE symbols used in the MIPS branch
> > to MIPS_KEYBOARD and MIPS_MOUSE. This is because the MOUSE symbol
> > seems to be used in different ways on different architectures (notably
> > in the Intel branch).
>
> An example of where merging completely independent config.in paths (Mips
> and Intel) causes a conflict :/
Yes. But this is a good conflict to be forced to resolve. The
multi-apex system has led to unnecessary complications and
duplications in the configuration-symbol namespace -- complications
which percolate up through the config tool to make kernel building
unnecessarily difficult. There is a particularly nasty case of this
near math emulation, for example.
> > Port maintainers and others with a continuing interest in the development
> > of CML2 should probably join the kbuild list -- subscribe in the usual
> > way via linux-kbuild-request@torque.net
>
> You should CC maintainers when their code is being discussed or
> updated. The onus of effort is on YOU to make your changes known.
> Otherwise you imply an unscalable model where maintainers must track
> every mailing list that could potentially discuss and affect their code.
I'm willing to make this effort. How do I go from a symbol to identifying
the relevant maintainer?
> Overall, I think it is high time that the config system was rewritten.
> While you are doing so, please consider two suggestions:
I think these are both fine ideas for later in the process. Right now
I want to stay focused on managing the transition to a clean language
and toolkit. That will position us to attack the larger problems --
which I *will* cheerfully take on, as they involve kinds of problems I
enjoy solving and am correspondingly good at.
-- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>Americans have the right and advantage of being armed - unlike the citizens of other countries whose governments are afraid to trust the people with arms. -- James Madison, The Federalist Papers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST