linux kernel conf 0.8

linux kernel conf 0.8

[Roman Zippel]

Hi,

At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of
the new config system.

As already mentioned before lkc is pretty much ready (except for kbuild
integration).
Linus, do you have any interest in merging it in the near future? If
not, what's missing?
The 2.5.40 release showed again, how bad three different parsers are, so
I think it's important to fix this finally for 2.6.

Changes this time:
- update to 2.5.41
- better error handling
- I introduced a few automaticly defined symbols (currently ARCH,
KERNELRELEASE, UNAME_RELEASE), which are currently only used for the
default location of the default config (e.g.
"/boot/config-$UNAME_RELEASE" or "arch/$ARCH/defconfig"), which are
currently still hardcoded, but could later be moved into Build.conf.
- more fine tuning
- I had to use my own Makefile again (Rules.make is slowly driving me
insane).

bye, Roman

Re: linux kernel conf 0.8

[Roman Zippel]

Hi,

On Tue, 8 Oct 2002, Linus Torvalds wrote:

> I'm not super-excited about this, partly because of the brouhaha last time
> around on this issue.
>
> This has reasonably distributed config files, and puts the help with the
> config entry where it belongs. Good. It also makes do with just standard
> unix tools, which is going to avoid one particular rat-hole, and which
> makes me at least understand the code. Also good.

Thanks. :)

> But the fact that xconfig depends on QT is going to make some people hate
> it.

This should be rather easily fixable, but it has to be done by someone who
is more familiar with whatever prefered toolkit. I'm familiar with QT and
it's absolutely great to get quickly reasonable results, if someone wants
something else I gladly will help, but I can't do it myself.
The interface to the back end is quite simple so it should be no real
problem to add a different user interface.

> And I haven't actually heard much _about_ this all, because
> (apparently as usual), all the discussion is held in a small world of its
> own.

Well, it happened mostly in my own world, so you didn't miss much. People
seemed to be scared because of the last discussion and are afraid to
invest some time into it. So far I had only some feedback from a few
people (for which I'm already thankful) and it where mostly interface
issues. All the coding work and major design decissions so far are my own.
So what you've seen so far on lkml is pretty much almost all the feedback
I got. It seems unless you state that you're not completely opposed to it,
I'm afraid it won't get better.

> In other words, I really think this needs to pass the linux-kernel stink
> test. Will Al Viro rip your throat out? Will it generate more positive
> feedback than death threats?
>
> Some things made me go eww (but on the whole details):
>
>  - I'd prefer the Config.in name, since this has nothing to do with
>    building, and everything to do with configuration.

Fine with me.
(jgarzik, I think you're overruled now. :) )

>  - I assume that the scripts are generated from the current Config.in
>    and Config.help files, and it would make me slightly happier to see the
>    diff as a "automatic script" + "diff to fix it up", just for doc
>    purposes.

All this is in the archive.

>  - that "lkc" name has got to go. Three-letter acronyms are not good. Of
>    course it's "linux kernel", the whole tree it sits in is "linux
>    kernel". Call it "config" or something obvious, please..

Fine with me too. I don't care much about names (as long as they make
sense) and I thought about a cool name, but I couldn't come up with
something, so if anyone has other suggestions...

>  - Quick testing showed that the first thing I tried didn't work: giving a
>    "?" as answer to the first question did _not_ result in help. "make
>    oldconfig" seemed to do the right thing, though.

Oops,that must have got lost somehow, it's fixed here.

> Let the flames begin.

Thanks, I hope this will help.
(Hmm, I hope your mail still makes it to lkml, in the meantime I left a
few more quotes than I usually would do.)

bye, Roman

Re: linux kernel conf 0.8

[Jeff Garzik]

Roman Zippel wrote:
> On Tue, 8 Oct 2002, Linus Torvalds wrote:
>>Some things made me go eww (but on the whole details):
>>
>> - I'd prefer the Config.in name, since this has nothing to do with
>>   building, and everything to do with configuration.
> 
> 
> Fine with me.
> (jgarzik, I think you're overruled now. :) )


Well, my basic preference is

* something other than Config.new (the original name in your config system)
* something other than Config.in

I think it is a mistake to name a totally different format the same name 
as an older format...  even "config.in" would be better than "Config.in"...

Re: linux kernel conf 0.8

[Roman Zippel]

Hi,

On Wed, 9 Oct 2002, Jeff Garzik wrote:

> Well, my basic preference is
>
> * something other than Config.new (the original name in your config system)
> * something other than Config.in
>
> I think it is a mistake to name a totally different format the same name
> as an older format...  even "config.in" would be better than "Config.in"...

My first plan was to use Config.in, but I can't overwrite the old files
yet, so I named it Config.new. Personally I only prefer that it starts
with a capital letter (like Makefile, Readme), so it's at the top of a
dir listing, but otherwise I don't care much about the name.

bye, Roman

Re: linux kernel conf 0.8

[Jeff Garzik]

Roman Zippel wrote:
> Hi,
> 
> On Wed, 9 Oct 2002, Jeff Garzik wrote:
> 
> 
>>Well, my basic preference is
>>
>>* something other than Config.new (the original name in your config system)
>>* something other than Config.in
>>
>>I think it is a mistake to name a totally different format the same name
>>as an older format...  even "config.in" would be better than "Config.in"...
> 
> 
> My first plan was to use Config.in, but I can't overwrite the old files
> yet, so I named it Config.new.

yeah, I understood it was a temporary name, I just wanted to make sure 
the name was changed fairly soonish, so we could have this filename 
debate :)


 > Personally I only prefer that it starts
> with a capital letter (like Makefile, Readme), so it's at the top of a
> dir listing, but otherwise I don't care much about the name.

That's fine with me.  My only preference is anything-but-Config.in, for 
the reason stated in the last email...

	Jeff

Re: linux kernel conf 0.8

[Sam Ravnborg]

On Wed, Oct 09, 2002 at 02:01:50PM +0200, Roman Zippel wrote:

> On Tue, 8 Oct 2002, Linus Torvalds wrote:
> > Some things made me go eww (but on the whole details):
> >
> >  - I'd prefer the Config.in name, since this has nothing to do with
> >    building, and everything to do with configuration.

Another suggestion about naming:
Take for example drivers/net:
cat Config.* | wc => 2149 lines

A bit a structure could be needed here.
Net.conf  <= Name equals directory with upper-case first letter
	- Cover the whole directory, and either implicit
	  or explicit include other .conf files in that directory
3c5xx.conf <= All the configuration for the 3c5xxx chipset drivers
rrunner.conf <= All configuration for rrunner driver

So letting the naming convention be directory name with upper-case start
letter - as the entry to a directory.
Additional configuration in sensibly named configuration files.
I do not see the split of configuration happen before 2.6, except in 
some special cases though. But I wanted to let the naming convention
support that.

source statements could look like:
source driver/net  <= since Net.conf is implicit
But I would prefer the files spelled out. 

> On Tue, 8 Oct 2002, Linus Torvalds wrote:
> >  - I assume that the scripts are generated from the current Config.in
> >    and Config.help files, and it would make me slightly happier to see the
> >    diff as a "automatic script" + "diff to fix it up", just for doc
> >    purposes.
> 
> All this is in the archive.

Keep both versions please. It's much easier just to apply a patch,
but I see why Linus ask for the other solution.
I know what version has preference ;-)

	Sam

Re: linux kernel conf 0.8

[Linus Torvalds]

On Wed, 9 Oct 2002, Sam Ravnborg wrote:
> 
> Another suggestion about naming:
> Take for example drivers/net:
> cat Config.* | wc => 2149 lines
> 
> A bit a structure could be needed here.
> Net.conf  <= Name equals directory with upper-case first letter
> 	- Cover the whole directory, and either implicit
> 	  or explicit include other .conf files in that directory
> 3c5xx.conf <= All the configuration for the 3c5xxx chipset drivers
> rrunner.conf <= All configuration for rrunner driver

Good point. Splitting up the big Config.in files is a good idea anyway, 
and it becomes even more important when the Config.help information was 
included in the file.

However, I disagree with the naming - I'd rather have one common name for
the "main" directory entry than have magic rules like "basename of the
directory capitalized". I don't want to have to search for it.

I also think I'd perfer to have them all start with the same thing, so 
that (again) it's clear when a directory has multiple configuration files. 

So instead: how about just "Config" for the main per-directory
configuration file, with sub-config's being "Config.3c5xx" and
"Config.rrunner".

		Linus

Re: linux kernel conf 0.8

[Sam Ravnborg]

On Wed, Oct 09, 2002 at 10:37:47AM -0700, Linus Torvalds wrote:
> However, I disagree with the naming - I'd rather have one common name for
> the "main" directory entry than have magic rules like "basename of the
> directory capitalized". I don't want to have to search for it.

OK, see your point here.

> I also think I'd perfer to have them all start with the same thing, so 
> that (again) it's clear when a directory has multiple configuration files. 
> 
> So instead: how about just "Config" for the main per-directory
> configuration file, with sub-config's being "Config.3c5xx" and
> "Config.rrunner".
I look at it the other way around. I want to make it clear that there
exist a separate Config file for a given subset of files. The normal
approach is to group files based on their filenames.
Therefore I prefer a fixed suffix, as opposed to a fixed prefix.

ls rrunner*
should show me not only the implementation [.c + .h] but also
the configuration.

The only reason I stick with the .conf prefix for the main per-directory
configuration file is to have a common suffix on all config files.

So I would suggest:

Config.conf		<= Main entry in any directory
sensible-name.conf	<= Any group of related files

ls *.conf 	list all configuration files.
ls rrunner*	list all files spcific for rrunner

It's so easy to have opinions about naming ;-)

	Sam

Re: linux kernel conf 0.8

[Linus Torvalds]

On Wed, 9 Oct 2002, Sam Ravnborg wrote:
> 
> ls rrunner*
> should show me not only the implementation [.c + .h] but also
> the configuration.

I agree with you, but only if we _always_ have one config file per driver. 

Which is not necessarily the wrong thing to do. 

But as long as most drivers are in "grouped" config files, they should be 
things like "Config.3com" etc.

Looking at existing big config files (video, networking), they do _not_ 
group according to driver, but according to other criteria (ie "PCI card", 
"100/1000 Mbit", "3com", "Sparc-specific" etc).

		Linus

Re: linux kernel conf 0.8

[Sam Ravnborg]

On Wed, Oct 09, 2002 at 11:47:16AM -0700, Linus Torvalds wrote:
> 
> On Wed, 9 Oct 2002, Sam Ravnborg wrote:
> > 
> > ls rrunner*
> > should show me not only the implementation [.c + .h] but also
> > the configuration.
> 
> I agree with you, but only if we _always_ have one config file per driver. 
> 
> Which is not necessarily the wrong thing to do. 
The question here is what we aim at.
And we aim at getting the configuration less centralized as compared with
what we have today.
I still remember the thread were you suggested the drivers.conf principle.
And I liked it then, and I like it today.
What I had to add a new driver to the kernel was to add the following
three files:
driver.c, driver,h driver.conf
Even the makefile stuff could be retreived from driver.conf.

> 
> But as long as most drivers are in "grouped" config files, they should be 
> things like "Config.3com" etc.
> 
> Looking at existing big config files (video, networking), they do _not_ 
> group according to driver, but according to other criteria (ie "PCI card", 
> "100/1000 Mbit", "3com", "Sparc-specific" etc).

But there is a good reason why they do it.
Take a look at dirvers/video/Config.in for example.
See the size of the big if's. They span several pages if not the whole file.
Why they do this is simple. Only check for PCI once, and group all
PCI stuff there.
With the syntax Roman propose we see instead that _each_ config option
check for PCI. Which is good IMHO.

The most logical grouping should be utilised, and grouping based on
bustype is not the grouping that we aim for.
We aim to group similar drivers together, if they happens to be for the
same bus or not should not matter.

But the whole argumentation boils down to something rahter simple:
1) Shall we group configuration files together
2) Shall we group related files together

And in mu opinion, if we decide not to use the filesystem namespace to
group similar files, then the incentive to break things out in smaller
files are mostly gone.
Except in the case where I sumbit a new driver and want to keep my
changes to the kernel file to a bare minimum, but then why not
let the config file be grouped with the rest of the driver.

Well I have raised my points, if you still prefer Config.* then let's
stick to that. This should but be the reason to delay lkc-roman.

	Sam

Re: linux kernel conf 0.8

[Jeff Garzik]

Sam Ravnborg wrote:
> But there is a good reason why they do it.
> Take a look at dirvers/video/Config.in for example.
> See the size of the big if's. They span several pages if not the whole file.
> Why they do this is simple. Only check for PCI once, and group all
> PCI stuff there.
> With the syntax Roman propose we see instead that _each_ config option
> check for PCI. Which is good IMHO.

That falls apart for multiple-bus drivers.

The way the current config files handle this seems reasonable...  for 
example drivers/net/ in fact _already_ splits things up by bus type to 
some extent.  But this is not a hard and fast rule, just easing some pain.


> But the whole argumentation boils down to something rahter simple:
> 1) Shall we group configuration files together
> 2) Shall we group related files together


This reminds me of another point:

An eventual goal is for people, mostly initial driver merges or vendors, 
to be able to add a simple driver without patching _any_ files.

Which implies that the equivalent of "source drivers/net/Config*" 
(wildcarding) in Roman's system would be useful.  Or maybe "source 
drivers/net" and it knows that when given a directory it should scan for 
all Config* files in that dir.

	Jeff

Re: linux kernel conf 0.8

[Roman Zippel]

Hi,

On Wed, 9 Oct 2002, Jeff Garzik wrote:

> Which implies that the equivalent of "source drivers/net/Config*"
> (wildcarding) in Roman's system would be useful.  Or maybe "source
> drivers/net" and it knows that when given a directory it should scan for
> all Config* files in that dir.

This makes dependency checking problematic, as we constantly have to
check for new config files. How would I teach make/kbuild this?

bye, Roman

Re: linux kernel conf 0.8

[Jeff Garzik]

Roman Zippel wrote:
> Hi,
> 
> On Wed, 9 Oct 2002, Jeff Garzik wrote:
> 
> 
>>Which implies that the equivalent of "source drivers/net/Config*"
>>(wildcarding) in Roman's system would be useful.  Or maybe "source
>>drivers/net" and it knows that when given a directory it should scan for
>>all Config* files in that dir.
> 
> 
> This makes dependency checking problematic, as we constantly have to
> check for new config files. How would I teach make/kbuild this?


I won't answer the question, but instead pose a future problem:  if 
drivers are to be added without patching anything, that implies that the 
kbuild makefile rules for the driver are also added without patching.

Personally I don't care about Config dependency checking...  they are 
not modified often enough to affect me, and even if they did, dependency 
checking based on changes to Config files can get ugly, AFAICS.  I just 
do a "bk -r co -Sq" and am done with it...

I didn't say life was easy ;-) ;-)

	Jeff

Re: linux kernel conf 0.8

[Sam Ravnborg]

[cc: trimmed]

On Thu, Oct 10, 2002 at 10:18:06AM -0400, Jeff Garzik wrote:
> Personally I don't care about Config dependency checking...  they are 
> not modified often enough to affect me, and even if they did, dependency 
> checking based on changes to Config files can get ugly, AFAICS.  I just 
> do a "bk -r co -Sq" and am done with it...
I care a lot about Config dependency checking, and you are not within the 
group of people that I care about in this respect.

kernel-hackers has no problem realising that a "make oldconfig" is needed.

But I care about NN that follows 2.6 development, and update his/her
tree each time a new version is posted at kernel.org.
This group of people needs dependency checking on Config files -
as can be seen by the number of reports that boils down to
"run make oldconfig".
Which we btw. have not seen the last couple of weeeks, but I still think
is good.

	Sam

Re: linux kernel conf 0.8

[Jeff Garzik]

Sam Ravnborg wrote:
> [cc: trimmed]
> 
> On Thu, Oct 10, 2002 at 10:18:06AM -0400, Jeff Garzik wrote:
> 
>>Personally I don't care about Config dependency checking...  they are 
>>not modified often enough to affect me, and even if they did, dependency 
>>checking based on changes to Config files can get ugly, AFAICS.  I just 
>>do a "bk -r co -Sq" and am done with it...
> 
> I care a lot about Config dependency checking, and you are not within the 
> group of people that I care about in this respect.
> 
> kernel-hackers has no problem realising that a "make oldconfig" is needed.
> 
> But I care about NN that follows 2.6 development, and update his/her
> tree each time a new version is posted at kernel.org.
> This group of people needs dependency checking on Config files -
> as can be seen by the number of reports that boils down to
> "run make oldconfig".


The kernel is written for people with a clue.  For people without a 
clue, they should use a vendor kernel or ESR's Aunt-Tillie-friendly system.

Dumbing-down the kernel is never the right answer.

	Jeff

Re: linux kernel conf 0.8

[Sam Ravnborg]

On Thu, Oct 10, 2002 at 01:32:11PM -0400, Jeff Garzik wrote:
> The kernel is written for people with a clue.  For people without a 
> clue, they should use a vendor kernel or ESR's Aunt-Tillie-friendly system.
> 
> Dumbing-down the kernel is never the right answer.

Well I'm not talking about dumbing-down the kernel. What I'm talking about
is to keep existing functionality.
For sure the kernel is made for people with a clue, but still people
with a clue sometimes makes stupid mistakes.

A build system that catches obvious stupid mistakes is IMHO a good thing.
But it shall not that for any cost, and the normal incremental build
shall continue to be as fast as possible.

	Sam

Re: linux kernel conf 0.8

[Jeff Garzik]

Linus Torvalds wrote:
> So instead: how about just "Config" for the main per-directory
> configuration file, with sub-config's being "Config.3c5xx" and
> "Config.rrunner".


I like it.  I'm glad Sam mentioned sub-configs such as Config.3c5xx, 
that's something that was discussed a while ago [and apparently we all 
forgot about it subsequently :)]

And the above eliminates my criticism of having "Config.in" be two 
different config languages, depending on your kernel version.

	Jeff

Re: [kbuild-devel] Re: linux kernel conf 0.8

[Christoph Hellwig]

On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Wed, 9 Oct 2002, Randy.Dunlap wrote:
> 
> > So I think that you and Roman are close to agreement, when Roman
> > has the library backend ready.  Of course someone needs to do a
> > "reference implementation" with it also, but it doesn't need to
> > ship with the kernel.
> 
> We ship BK documentation, so shipping a small QT app can't be that
> problematic. :)
> Creating the library isn't that difficult (kbuild is currently my
> problem here) and I'll still have to write some API documentation for it
> and some glue code to load the library.

Why don't you just separate the library from the kernel at all, making
it a similar package.  We depend on a few external, kernel-specific
packages anyway, and depending on libkconfig wouldn't make the situation
worse.  Instead people could keep their tools build one time around in
/usr/{local/,}bin (especially important with qt-monsters :)) and if
there is a change in the language Documentation/Changes would get
updated to the new required version and people had to update it,
similar to the gcc situation for a new development kernel.

Re: [kbuild-devel] Re: linux kernel conf 0.8

[Roman Zippel]

Hi,

On Wed, 9 Oct 2002, Christoph Hellwig wrote:

> Why don't you just separate the library from the kernel at all, making
> it a similar package.  We depend on a few external, kernel-specific
> packages anyway, and depending on libkconfig wouldn't make the situation
> worse.

The problem is that the config syntax will continue to evolve and
currently I prefer to keep the library close to the matching config
files.
I think I can keep the basic structure constant, but new options will be
added, so IMO it's more likely that a front end works with a newer
library than that a library can understand a newer syntax.

bye, Roman

Re: linux kernel conf 0.8

[Peter Samuelson]

[Roman Zippel]
> The problem is that the config syntax will continue to evolve and
> currently I prefer to keep the library close to the matching config
> files.
> I think I can keep the basic structure constant, but new options will be
> added, so IMO it's more likely that a front end works with a newer
> library than that a library can understand a newer syntax.

Besides which, I think it is ridiculous that one would have to download
and install a "kernel configurator" just to build a kernel.  Current
minimum requirements for compiling the thing are gcc, binutils and GNU
make.  The kernel can't very well ship a copy of any of those, because
(a) they're huge and (b) they're useful for many things other than
building kernels.  Roman's library is neither.

(And no, "modutils" isn't a counterexample - you can build, install and
run a kernel without it.)

Peter

Re: linux kernel conf 0.8

[Randy.Dunlap]

On Wed, 9 Oct 2002, Peter Samuelson wrote:

| [Roman Zippel]
| > The problem is that the config syntax will continue to evolve and
| > currently I prefer to keep the library close to the matching config
| > files.
| > I think I can keep the basic structure constant, but new options will be
| > added, so IMO it's more likely that a front end works with a newer
| > library than that a library can understand a newer syntax.
|
| Besides which, I think it is ridiculous that one would have to download
| and install a "kernel configurator" just to build a kernel.  Current
| minimum requirements for compiling the thing are gcc, binutils and GNU
| make.  The kernel can't very well ship a copy of any of those, because
| (a) they're huge and (b) they're useful for many things other than
| building kernels.  Roman's library is neither.

Well, we all find some things more ridiculous than others, but...

The kernel would still have the text-mode configurator.
This only applies to the GUI kernel config.
So you wouldn't have to download the kernel config unless you just
wanted that oh-so-pretty GUI to config it.

[rhetorical question:]
So should it be shipped with a full Qt development environment, e.g.?

| (And no, "modutils" isn't a counterexample - you can build, install and
| run a kernel without it.)

-- 
~Randy
  "In general, avoiding problems is better than solving them."
  -- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.

Re: linux kernel conf 0.8

[Sam Ravnborg]

On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
> 
> The kernel would still have the text-mode configurator.
The way I read the original post by Christoph Hellwig - nope.
If the kernel config library is outside the kernel then the
text-mode versions will fail as well.
Recall that the text-mode version are no longer shell scripts,
but based on a nice YACC grammar and coded in C.

I do not want to go somewhere for special tools just to configure
the kernel.
Basic stuff such as make and gcc is ok to locate elsewhere - in
specific versions as well. But not some basic kernel only configurator.

	Sam

Re: linux kernel conf 0.8

[Randy.Dunlap]

On Wed, 9 Oct 2002, Sam Ravnborg wrote:

| On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
| >
| > The kernel would still have the text-mode configurator.
| The way I read the original post by Christoph Hellwig - nope.
| If the kernel config library is outside the kernel then the
| text-mode versions will fail as well.
| Recall that the text-mode version are no longer shell scripts,
| but based on a nice YACC grammar and coded in C.

OK, I missed that.  Sorry.
In that case I might fall into the "ridiculous" camp.  :)

| I do not want to go somewhere for special tools just to configure
| the kernel.
| Basic stuff such as make and gcc is ok to locate elsewhere - in
| specific versions as well. But not some basic kernel only configurator.

-- 
~Randy
  "In general, avoiding problems is better than solving them."
  -- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.