Re: linux kernel conf 0.8

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: [kbuild-devel] Re: linux kernel conf 0.8

[Brendan J Simon]

Roman Zippel 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.
>

Simple and boring but how about "Config2.in" or "Config-2.in" ???

Regards,
Brendan Simon.

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

[Jeff Garzik]

Brendan J Simon wrote:
> Simple and boring but how about "Config2.in" or "Config-2.in" ???

no offense intended, but:

	ug...

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

[Brendan J Simon]

Roman Zippel wrote:

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

This is a difficult one.  GUI's toolkits are a bit of religion 
(fundamentalist types too).

I like and use GNOME.  KDE looks good too but I steered away from it in 
the early days due to the Qt licensing.  I've heard rumors that the new 
license is GPL compatible but I get the feeling that it is still not 
squeeky clean.  A lot of people don't like the larger resources for 
these desktop environments.

The most common GUI toolkits used in Linux would be GTK, Qt, 
Lesstif/Motif and Xaw (I've probably missed some).  Xaw will work on 
just about every platform I think, not sure about the others on non 
linux platforms apart from lesstiff.

I personally believe in cross platform GUI toolkits and use wxWindows 
for this.  I really like wxpython (GTK and MSW only) for quick 
development.  I believe there are python wrappers to most toolkits (Qt, 
GTK, etc).

As you can see there are soooooo many guis to choose/use and everyone 
has there favourite.  I suggest that the real work be done outside of 
the GUI program.  ie. seperate GUI and application guts as much as 
possible.  I would use python as the main language but C or even C++ 
could be used instead as a lot of people hate interpreters, or hate 
python (prefer perl, php or something else).

I'm pretty sure there is no one solution and it comes down to the 
politics and preferences of the final decision makers up the heirarchy.

Good luck,
Brendan Simon.

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

[Randy.Dunlap]

On Thu, 10 Oct 2002, Brendan J Simon wrote:

| Roman Zippel wrote:
|
| >>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.
| >
|
| This is a difficult one.  GUI's toolkits are a bit of religion
| (fundamentalist types too).
|
[good descriptions snipped]
|
| I'm pretty sure there is no one solution and it comes down to the
| politics and preferences of the final decision makers up the heirarchy.
|
| Good luck,

stick with TCL/TK, like xconfig currently uses ?
or is it not sufficient?  or just too ugly?

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

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

[J.A. Magallon]

On 2002.10.09 Randy.Dunlap wrote:
>On Thu, 10 Oct 2002, Brendan J Simon wrote:
>
>| Roman Zippel wrote:
>|
>| >>But the fact that xconfig depends on QT is going to make some people hate
>| >>it.
>| >>
...
>| This is a difficult one.  GUI's toolkits are a bit of religion
>| (fundamentalist types too).
>|
...
>
>stick with TCL/TK, like xconfig currently uses ?
>or is it not sufficient?  or just too ugly?
>

What is linux kernel conf written in ?
- perl: use perl-gtk (I think there is also a perl-qt)
- python: use py-gtk...

Use whatever the language gives. I never undestook why use tcl/tk
on a perl/python config system.


-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre10-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))

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

[Roman Zippel]

Hi,

On Wed, 9 Oct 2002, J.A. Magallon wrote:

> >stick with TCL/TK, like xconfig currently uses ?
> >or is it not sufficient?  or just too ugly?
> >
>
> What is linux kernel conf written in ?
> - perl: use perl-gtk (I think there is also a perl-qt)
> - python: use py-gtk...
>
> Use whatever the language gives. I never undestook why use tcl/tk
> on a perl/python config system.

With the exception of the X interface everything is in C, what makes it
difficult to use script languages, one always needs some extra development
package installed. That's the main reason for creating a library backend,
a lot can already be packaged by distributions and only the library needs
to be built from the current kernel.

bye, Roman

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

[Linus Torvalds]

On Wed, 9 Oct 2002, Randy.Dunlap wrote:
> 
> stick with TCL/TK, like xconfig currently uses ?

Too ugly. I actually think QT is a fine choice, I just suspect that it's 
going to cause political issues.

My favourite approach by far is to actually not ship anything graphical
with the kernel at all, and just hope that the config language syntax is
stable enough that different groups can do their own as external packages.  

The kernel would ship with just the text-based "reference implementation"  
(if even that - we could just have a few "supporting packages").

The only thing I personally really care about is the Config language, 
since that _has_ to ship with the kernel. 

		Linus

PS. And while we're talking about the language - I'd actually prefer the
syntax "depends on" or "requires" instead of "depends", to make it
grammatically more correct. And those help-texts should be separated some
way so that they don't blend in quite as badly with the "command section".
Maybe something really syntactic like just replacing the "help" keyword
with a "---help---"  keyword.

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

[Randy.Dunlap]

On Wed, 9 Oct 2002, Linus Torvalds wrote:

| On Wed, 9 Oct 2002, Randy.Dunlap wrote:
| >
| > stick with TCL/TK, like xconfig currently uses ?
|
| Too ugly. I actually think QT is a fine choice, I just suspect that it's
| going to cause political issues.
|
| My favourite approach by far is to actually not ship anything graphical
| with the kernel at all, and just hope that the config language syntax is
| stable enough that different groups can do their own as external packages.

Good.  I was this -><- close to suggesting "no GUI" -- just didn't
send that part of the message.

| The kernel would ship with just the text-based "reference implementation"
| (if even that - we could just have a few "supporting packages").
|
| The only thing I personally really care about is the Config language,
| since that _has_ to ship with the kernel.

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.

| 		Linus
|
| PS. And while we're talking about the language - I'd actually prefer the
| syntax "depends on" or "requires" instead of "depends", to make it
| grammatically more correct. And those help-texts should be separated some
| way so that they don't blend in quite as badly with the "command section".
| Maybe something really syntactic like just replacing the "help" keyword
| with a "---help---"  keyword.

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

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

[Roman Zippel]

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.

bye, Roman

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.

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

[Roman Zippel]

Hi,

On Thu, 10 Oct 2002, Brendan J Simon wrote:

> As you can see there are soooooo many guis to choose/use and everyone
> has there favourite.  I suggest that the real work be done outside of
> the GUI program.  ie. seperate GUI and application guts as much as
> possible.  I would use python as the main language but C or even C++
> could be used instead as a lot of people hate interpreters, or hate
> python (prefer perl, php or something else).
>
> I'm pretty sure there is no one solution and it comes down to the
> politics and preferences of the final decision makers up the heirarchy.

Because of this I'm planning to make the config backend available as
shared library, so it can be loaded by external programs. My QT app then
would be basically just the reference implementation.
I also want to add a SWIG interface file, so you can even access the
config database with your preferred script language.

bye, Roman

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: [kbuild-devel] Re: linux kernel conf 0.8

[Brendan J Simon]

Sam Ravnborg wrote:

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

I really like this.  It's just so intuative :)

Brendan Simon.

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

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