Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Thu, 24 Nov 2005, Rob Landley wrote:

> > On Mon, 21 Nov 2005, Rob Landley wrote:
> > > Add "make miniconfig", plus documentation, plus the script that creates a
> > > minimal mini.config from a normal .config file.
> >
> > The difference between miniconfig and allnoconfig is IMO too small to be
> > really worth it right now.
> 
> I disagree, fairly strongly.  The technical difference may be small, but the 
> conceptual difference is huge.

I don't really disagree, a proper implementation of the concept would also 
be technically quite different. Hacking it into conf.c is the wrong to go 
(or to even start).

> > which is only read by kconfig.
> 
> So it would be different from the format of the busybox .config file, the 
> uClibc .config file, or anybody else out there who's adopted the kernel's 
> format over the past decade-plus?

Did I say it would go away? No.
It actually makes quite some sense to separate the .config used by kbuild 
from the config used by kconfig.
.config isn't always correctly reread after a manual edit. The syntax 
rules needed by kbuild are more strict than needed for kconfig. The "is 
not set" syntax is not exactly user friendly and all the derived symbols 
aren't needed by kconfig.
My current plan is to somewhere create a copy of .config replacing 
the include/config/MARKER mechanism, which then is also used by kbuild.
In a second step it then would be simple to allow an alternative name 
or even formats for the primary config file.

> 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?

> So how would you make use of this new minimized version, then?  If somebody 
> file attached one in a linux kernel message and a developer wanted to debug 
> their issue?

$ cp ... linux/config
$ make

> I don't personally _care_ about the other config targets.

Well, that's the problem, I do care about them. 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.

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/