Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Fri, 25 Nov 2005, Rob Landley wrote:

> > I don't really disagree, a proper implementation of the concept would also
> > be technically quite different.
> 
> But would the user interface?

It would be a bit different from what you propose.

> Uh-huh.  So doing this requires a complete rewrite of kconfig.  And how long 
> is this rewrite expected to take?  (Will it be in python and called CML2?)

Rob, if you want me to just ignore you, then please continue like this.

> Meanwhile, I have a small patch that provides this (from a user perspective) 
> now.  Working today.

The point is that it's close enough to allnoconfig, so that it's IMO not 
worth it. I'm trying to explain, what would be needed to do it properly, 
but either I failed to make myself understandable or you're not listening.

> > > However, you seem to be forgetting that .config is read by the kernel
> > > build infrastructure.  The tools are generating what _used_ to be a human
> > > editable file.
> >
> > Oh, really?
> 
> This is a slightly vague.  Is this "Oh, really?" arguing that it didn't used 
> to be a human readable format?

At this point I was just wondering, whether you realize that I wrote the 
new kconfig stuff.

> > > I don't personally _care_ about the other config targets.
> >
> > Well, that's the problem, I do care about them.
> 
> I think you're too focused on the implementation to see the users.  What I'm 
> trying to document is miniconfig, and as such any kallsyms target allnoconfig 
> is not _useful_.

I'm actually quite interested in the needs of the users, but OTOH users 
have to realize that they are not always _exactly_ get what they want. 
Users often have very specific wishes and I try to provide a generic 
framework, which not only solves specific problems but also a broad range 
of problems, which often means to compromise as user needs can be very 
contradictory.

> > I want to keep it working without obfuscating it with thousands little
> > features, so we have to figure out how to integrate it properly into the big
> > picture. 
> 
> Do you have a suggestion that does not involve a complete rewrite of kbuild 
> over the next year or more?  I just posted one, and I've just started work on 
> another.
> 
> I'm still not entirely certain you understand what I'm trying to accomplish, 
> and I'm sorry I can't make you understand why I need this.  I'm not convinced 
> that your "new config format" will be at all useful.

I think I understand you quite well. Again, the basic functionality you 
want is already provided by allnoconfig and the advanced features need a 
bit more work than the few hacks you added to conf.c.
I like the idea of a minimum config, which e.g. users can send to 
developers or they can use for upgrading kernels, but this has to work not
just for you, but also for the majority of users and this requires a 
better specification of how this feature should work in various 
situations.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/