Hi,
After all the flam^Wdiscussion about cml2 I decided to something more
constructive and try to do the impossible (and as lkml was dead I hadn't
much choice :) ).
At http://www.xs4all.nl/~zippel/lkcc.tar.gz there is a small program which
converts the config files into an alternative format. The tool expects a
Configure.help in the root of the kernel tree, so a "find -name
Config.help | xargs cat >> Configure.help" is needed, then start it with
"lc arch/<arch>/config.in".
The output is completely unsorted, so all menu information isn't there
(but that is easy to change), Otherwise it has the same information for
every symbol as the normal config files.
The current output looks like this:
config: ULTRIX_PARTITION
define_bool
default: y
dep: ((!PARTITION_ADVANCED?) && DECSTATION=y)
bool
prompt: Ultrix partition table support
dep: PARTITION_ADVANCED?
help:
Say Y here if you would like to be able to read the hard disk
partition table format used by DEC (now Compaq) Ultrix machines.
Otherwise, say N.
Now I'm curious what advantages cml2 has. I'm seeing a quite complex
specification with lots of features and I'm not sure whether all this is
really required. IMO Eric tries to solve a more complex problem and I
think this problem isn't relevant for the kernel configuration, so what
we can do is to reduce the problem complexity. This means we can make sure
that dependencies are strictly hierarchical (the tool checks for that),
this would make working with the rules far easier (implementing a 'make
oldconfig' would be very simple).
What am I missing now, that we can't convert the current configs into
something like above and add new features later to it? I don't know if
above can be changed into something that looks more like cml2, but the
most important property of this is that we don't have to do all the
conversion at once. Some things can/should already be fixed in cml1, so
that the generated files only needs minimal changes and both can be tested
and used at the same time until we abandon cml1. After that we can think
about new features, like including build information.
Some technical notes about the tool:
- I implemented a few simple optimizations to make the dependencies easier
readable, there of course far more possible, but some changes could be
done at the original config files to make this easier, e.g. dependencies
can there already be simplified. Another problem is that one can set some
tristate symbols to 'y' although another dependent symbol is set to 'm'
(e.g. for CONFIG_FB_MATROX/CONFIG_FB_MATROX_G450 it goes wrong). This is
something that IMO should be checked and fixed in cml1 first.
- The output for choices represents the internal implementation, so that
definitely needs a new syntax. On the other hand the remaining syntax of
course needs to be improved as well.
- Dependencies include the type of the symbol if possible ('?' - boolean,
'??' - tristate, '*' - data), it isn't complete yet, since some symbols
are only defined for some architectures. A complete dependency graph for
all archs would certainly be interesting. :)
- The program is just a small hack done within a dew days, please keep
this in mind, when looking at it. :) So don't expect any comments and the
structure is still quite chaotic. On the other hand the program isn't
supposed to be used forever.
bye, Roman
Roman Zippel wrote:
> At http://www.xs4all.nl/~zippel/lkcc.tar.gz there is a small program which
> converts the config files into an alternative format. The tool expects a
[...]
> The current output looks like this:
>
> config: ULTRIX_PARTITION
> define_bool
> default: y
> dep: ((!PARTITION_ADVANCED?) && DECSTATION=y)
> bool
> prompt: Ultrix partition table support
> dep: PARTITION_ADVANCED?
> help:
> Say Y here if you would like to be able to read the hard disk
> partition table format used by DEC (now Compaq) Ultrix machines.
> Otherwise, say N.
[...]
> What am I missing now, that we can't convert the current configs into
> something like above and add new features later to it?
Interesting...
FWIW a much better transition path is very close to what your tool does,
and is a suggestion made by mec (kbuild maintainer) near the end of the
recent flamewar: convert config.in files one at a time, like we did the
old makefiles.
That would imply a rewrite of make [old]config, and an updating of make
menu|xconfig, to handle the new format...
As it happened with the conversion to new-style Makefiles, Linus may say
"bah" when the conversion 80% there, and remove support for the old
config format completely. :)
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
Hi,
On Thu, 21 Feb 2002, Jeff Garzik wrote:
> FWIW a much better transition path is very close to what your tool does,
> and is a suggestion made by mec (kbuild maintainer) near the end of the
> recent flamewar: convert config.in files one at a time, like we did the
> old makefiles.
That's possible, as soon as the menu information is added, both formats
contain the same information, so a program with two parsers can handle
both simultaneously.
> That would imply a rewrite of make [old]config, and an updating of make
> menu|xconfig, to handle the new format...
I think we should just dump the old tools and implement a single config
library, which exports an interface to access the config information.
bye, Roman
Roman Zippel wrote:
> On Thu, 21 Feb 2002, Jeff Garzik wrote:
> > FWIW a much better transition path is very close to what your tool does,
> > and is a suggestion made by mec (kbuild maintainer) near the end of the
> > recent flamewar: convert config.in files one at a time, like we did the
> > old makefiles.
>
> That's possible, as soon as the menu information is added, both formats
> contain the same information, so a program with two parsers can handle
> both simultaneously.
yep
> > That would imply a rewrite of make [old]config, and an updating of make
> > menu|xconfig, to handle the new format...
>
> I think we should just dump the old tools and implement a single config
> library, which exports an interface to access the config information.
I do not think we can -avoid- dumping scripts/Configure[1], replacing
the existing tools. In that respect I agree with Eric and the others.
So your proposition makes sense. But the configuration language can and
should be migrated, IMO.
Jeff
[1] Sure you could code a replacement parser in bash shell script. But
that's just wanking, like a Georgia Tech professor of mine: he
implemented a visual Towers of Hanoi solver in vi macros. We all
thought it was cool but ultimately CS wanking of no real value :)
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Thu Feb 21, 2002 at 11:48:59AM +0100, Roman Zippel wrote:
> The current output looks like this:
>
> config: ULTRIX_PARTITION
> define_bool
> default: y
> dep: ((!PARTITION_ADVANCED?) && DECSTATION=y)
> bool
> prompt: Ultrix partition table support
> dep: PARTITION_ADVANCED?
> help:
> Say Y here if you would like to be able to read the hard disk
> partition table format used by DEC (now Compaq) Ultrix machines.
> Otherwise, say N.
I like this. It's simple, its clean, and it keeps all the
information in one spot. I think we can go a bit farther here
and add in a list of the .c files that enabling this feature
should add to the Makefile (per the current
obj-$(CONFIG_FOO) += foo.o
stuff in the current Makefile).
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
> I like this. It's simple, its clean, and it keeps all the
> information in one spot. I think we can go a bit farther here
> and add in a list of the .c files that enabling this feature
> should add to the Makefile (per the current
> obj-$(CONFIG_FOO) += foo.o
> stuff in the current Makefile).
Hey, you're skipping ahead to the cool chapters!
Seriously, yep, that's exactly where we eventually want to be: all
config, makefile, and help text info in one place. To add a new net
driver, I want to be able to simply add two files, driver.c and
driver.conf, and be done with it.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
Roman Zippel wrote:
> Hi,
>
> config: ULTRIX_PARTITION
> define_bool
> default: y
> dep: ((!PARTITION_ADVANCED?) && DECSTATION=y)
> bool
> prompt: Ultrix partition table support
> dep: PARTITION_ADVANCED?
> help:
> Say Y here if you would like to be able to read the hard disk
> partition table format used by DEC (now Compaq) Ultrix machines.
> Otherwise, say N.
>
From old discussion in kbuild list:
1) default: Eric proposed to include defaults in configuration,
but it seems that is a bad things, and defaults should be arch
specific. (I don't remember the discussion, but you can
parse the kbuild list, torque.net time)
2) One of the problem in actual configure are the dependencies.
FOO depend on BAR and BEER.
Wat are the possible value of FOO if BAR=m, BEER=y.
In kernel we have some drivers thet need foo to be n or y,
in other cases: n or m.
The logical operators hide the true dependency table.
(don't expect developers read the docs: the logical operators
seems like C operators, so they use like C, but they forget
the third case (=m) ).
Do you use the python identation mode?
giacomo
Hi,
On Thu, 21 Feb 2002, Giacomo Catenazzi wrote:
> 1) default: Eric proposed to include defaults in configuration,
> but it seems that is a bad things, and defaults should be arch
> specific. (I don't remember the discussion, but you can
> parse the kbuild list, torque.net time)
The defaults are just 1:1 representation of the current define_xxx
statements. These can be of course later moved or depreciated or whatever.
> 2) One of the problem in actual configure are the dependencies.
> FOO depend on BAR and BEER.
> Wat are the possible value of FOO if BAR=m, BEER=y.
> In kernel we have some drivers thet need foo to be n or y,
> in other cases: n or m.
> The logical operators hide the true dependency table.
> (don't expect developers read the docs: the logical operators
> seems like C operators, so they use like C, but they forget
> the third case (=m) ).
For most cases I've seen it can be very simply defined with:
(a && b && ...) = min(a, b, ...)
(a || b || ...) = max(a, b, ...)
for 'n'=0, 'm'=1, 'y'=2
I have to check the other cases and I haven't look too closely, yet, but
e.g. in this case it goes wrong:
config: FB_MATROX_G450
dep_tristate
prompt: G450/G550 second head support
dep: (VT? && EXPERIMENTAL? && FB? && EXPERIMENTAL? && PCI? && FB_MATROX??!=n && FB_MATROX_G100?)
CONFIG_FB_MATROX_G450 can be defined to 'y' and CONFIG_FB_MATROX to 'm',
the result is that the build goes wrong. By removing '!=n' above rule
would produce the correct result.
Do you have some real examples?
> Do you use the python identation mode?
No python. Just c, flex and bison. :-)
bye, Roman
Jeff Garzik wrote:
> Erik Andersen wrote:
>
>>I like this. It's simple, its clean, and it keeps all the
>>information in one spot. I think we can go a bit farther here
>>and add in a list of the .c files that enabling this feature
>>should add to the Makefile (per the current
>> obj-$(CONFIG_FOO) += foo.o
>>stuff in the current Makefile).
>
> Seriously, yep, that's exactly where we eventually want to be: all
> config, makefile, and help text info in one place. To add a new net
> driver, I want to be able to simply add two files, driver.c and
> driver.conf, and be done with it.
with kbuild-2.5 this can be done easy. We should maintain
the syntax of kbuild-2.5 (or a subset).
But the makefile/makefile.in will remain: not all code
in kernel is drivers, and for the non drivers makefile/config.in
IMHO it is better to have 'central' (per directory/per type)
config and makefile files.
giacomo
Giacomo Catenazzi wrote:
>
> Jeff Garzik wrote:
>
> > Erik Andersen wrote:
> >
> >>I like this. It's simple, its clean, and it keeps all the
> >>information in one spot. I think we can go a bit farther here
> >>and add in a list of the .c files that enabling this feature
> >>should add to the Makefile (per the current
> >> obj-$(CONFIG_FOO) += foo.o
> >>stuff in the current Makefile).
> >
> > Seriously, yep, that's exactly where we eventually want to be: all
> > config, makefile, and help text info in one place. To add a new net
> > driver, I want to be able to simply add two files, driver.c and
> > driver.conf, and be done with it.
>
> with kbuild-2.5 this can be done easy. We should maintain
> the syntax of kbuild-2.5 (or a subset).
>
> But the makefile/makefile.in will remain: not all code
> in kernel is drivers, and for the non drivers makefile/config.in
> IMHO it is better to have 'central' (per directory/per type)
> config and makefile files.
yes and no :)
We do not want to limit one-driver one-file, just support it.
And, makefile information needs to be included along with config
information. For a more realistic example, when I add a new net driver,
I would modify
drivers/net/new-driver.c
drivers/net/net-drivers.conf
and the second file includes the makefile rules necessary to build
things.
For directories like kernel/* and mm/* and arch/*, I imagine that down
the road we will want kernel.conf and mm.conf too, though right now they
would probably remain as makefiles...
If you look closely at the problem, you will see there is no fundamental
reason why we cannot package makefile rules like we want to package
config information.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
1. does this handle the cross directory dependancies?
2. does it handle the 'I want this feature, turn on everything I need for
it'?
3. if it handles #2 what does it do if you turn off that feature again
(CML2 turns off anything it turned on to support that feature, assuming
nothing else needs it)
David Lang
On Thu, 21 Feb 2002, Jeff Garzik wrote:
> Date: Thu, 21 Feb 2002 08:21:51 -0500
> From: Jeff Garzik <[email protected]>
> To: [email protected]
> Cc: Roman Zippel <[email protected]>, [email protected]
> Subject: Re: linux kernel config converter
>
> Erik Andersen wrote:
> > I like this. It's simple, its clean, and it keeps all the
> > information in one spot. I think we can go a bit farther here
> > and add in a list of the .c files that enabling this feature
> > should add to the Makefile (per the current
> > obj-$(CONFIG_FOO) += foo.o
> > stuff in the current Makefile).
>
> Hey, you're skipping ahead to the cool chapters!
>
> Seriously, yep, that's exactly where we eventually want to be: all
> config, makefile, and help text info in one place. To add a new net
> driver, I want to be able to simply add two files, driver.c and
> driver.conf, and be done with it.
>
> Jeff
>
>
>
> --
> Jeff Garzik | "Why is it that attractive girls like you
> Building 1024 | always seem to have a boyfriend?"
> MandrakeSoft | "Because I'm a nympho that owns a brewery?"
> | - BBC TV show "Coupling"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
David Lang wrote:
> 1. does this handle the cross directory dependancies?
I presume you are talking about Roman's tool, so I'll let him answer. I
think he just implemented a converter to a new language, so new language
tools to parse the language don't exist yet, I think.
> 2. does it handle the 'I want this feature, turn on everything I need for
> it'?
This is fundamentally impossible for anything beyond the most simple
features. Although you can do a lot with config.in info, "everything I
need" is something a human needs to define in many cases.
> 3. if it handles #2 what does it do if you turn off that feature again
> (CML2 turns off anything it turned on to support that feature, assuming
> nothing else needs it)
This is a policy decision. I'm not sure one -wants- to do this...
Doing something like this blindly can have unintended side effects, i.e.
violate the Principle of Least Surprise.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
Roman Zippel wrote:
> Hi,
>
> On Thu, 21 Feb 2002, Giacomo Catenazzi wrote:
>
>
>>1) default: Eric proposed to include defaults in configuration,
>> but it seems that is a bad things, and defaults should be arch
>> specific. (I don't remember the discussion, but you can
>> parse the kbuild list, torque.net time)
>>
>
> The defaults are just 1:1 representation of the current define_xxx
> statements. These can be of course later moved or depreciated or whatever.
Ok. But actually the defaults come mainly from config.def.
The define_xxx are uset to set a symbols in some situations.
BTW for people who like the old configure (or fix it):
: if xxx
: define_bool CONFIG_FOO
: else
: bool CONFIG_FOO
: fi
is incorrect. You should revert the definition order
(before bool than define_bool) else xconfig will break.
>>2) One of the problem in actual configure are the dependencies.
>> FOO depend on BAR and BEER.
>> Wat are the possible value of FOO if BAR=m, BEER=y.
>> In kernel we have some drivers thet need foo to be n or y,
>> in other cases: n or m.
>> The logical operators hide the true dependency table.
>> (don't expect developers read the docs: the logical operators
>> seems like C operators, so they use like C, but they forget
>> the third case (=m) ).
>>
>
> For most cases I've seen it can be very simply defined with:
> (a && b && ...) = min(a, b, ...)
> (a || b || ...) = max(a, b, ...)
> for 'n'=0, 'm'=1, 'y'=2
With this you have a value (i.e. n,m,y).
How is the actual symbol range?
CONFIG_FOO:
dep: (FREE? && BEER?)
how you tell configuration rools that
FOO can be only min/max of (FREE? && BEER?)
> Do you have some real examples?
No by hand. But I can search in rules.
>>Do you use the python identation mode?
>>
>
> No python. Just c, flex and bison. :-)
I mean: Do you use pythons mode to tell when a
help description end (no tab: new symbol), few spaces:
is symbol help or configuration symbols)
giacomo
Jeff Garzik wrote:
>>
> For directories like kernel/* and mm/* and arch/*, I imagine that down
> the road we will want kernel.conf and mm.conf too, though right now they
> would probably remain as makefiles...
>
> If you look closely at the problem, you will see there is no fundamental
> reason why we cannot package makefile rules like we want to package
> config information.
I agree that in most case (drivers) it is the right thing.
But for kernel/, arch/ there are no simple way to tell:
"this makefile rule belong to this configuration".
In such cases we should not split makefiles and configurations
in an artificial way.
We should not generalize and split configuration and makefile
just because in most case it is the right thing.
[ Some Makefile define at the beginning some flags that
should be used for all driver in such subdir.
These info should be in a 'main' .conf (main = where normal
user would check, without grep to all .conf)
]
giacomo
On Thu, 21 Feb 2002, Jeff Garzik wrote:
> David Lang wrote:
> > 1. does this handle the cross directory dependancies?
>
> I presume you are talking about Roman's tool, so I'll let him answer. I
> think he just implemented a converter to a new language, so new language
> tools to parse the language don't exist yet, I think.
I am so I'll wait for his answer
> > 2. does it handle the 'I want this feature, turn on everything I need for
> > it'?
>
> This is fundamentally impossible for anything beyond the most simple
> features. Although you can do a lot with config.in info, "everything I
> need" is something a human needs to define in many cases.
>
unless I am missing something this is one of the features that CML2
implements. Agreed that 'everything I need' needs to be defined by a
human, that's what Eric has done in his ruleset, define the dependancies.
>
> > 3. if it handles #2 what does it do if you turn off that feature again
> > (CML2 turns off anything it turned on to support that feature, assuming
> > nothing else needs it)
>
> This is a policy decision. I'm not sure one -wants- to do this...
> Doing something like this blindly can have unintended side effects, i.e.
> violate the Principle of Least Surprise.
I'll argue that _not_ doing this violated the principle of lease surprise,
if you turn a feature on and immediatly back off why should anything in
your config be any different then it was before you turned it on?
David Lang
David Lang wrote:
>
> 2. does it handle the 'I want this feature, turn on everything I need for
> it'?
>
> 3. if it handles #2 what does it do if you turn off that feature again
> (CML2 turns off anything it turned on to support that feature, assuming
> nothing else needs it)
These are tools dependent and not language dependent.
Please split the two problem: the language and the configuration
tools.
giacomo
On Thu, 21 Feb 2002, Giacomo Catenazzi wrote:
> David Lang wrote:
>
> >
> > 2. does it handle the 'I want this feature, turn on everything I need for
> > it'?
> >
> > 3. if it handles #2 what does it do if you turn off that feature again
> > (CML2 turns off anything it turned on to support that feature, assuming
> > nothing else needs it)
>
>
> These are tools dependent and not language dependent.
> Please split the two problem: the language and the configuration
> tools.
#3 may be, but #2 isn't possible if the language doesn't provide enough
info for the tool to know what is needed to make a feature work.
David Lang
David Lang wrote:
>
> On Thu, 21 Feb 2002, Jeff Garzik wrote:
>
> > David Lang wrote:
> > > 1. does this handle the cross directory dependancies?
> >
> > I presume you are talking about Roman's tool, so I'll let him answer. I
> > think he just implemented a converter to a new language, so new language
> > tools to parse the language don't exist yet, I think.
>
> I am so I'll wait for his answer
>
> > > 2. does it handle the 'I want this feature, turn on everything I need for
> > > it'?
> >
> > This is fundamentally impossible for anything beyond the most simple
> > features. Although you can do a lot with config.in info, "everything I
> > need" is something a human needs to define in many cases.
> >
>
> unless I am missing something this is one of the features that CML2
> implements. Agreed that 'everything I need' needs to be defined by a
> human, that's what Eric has done in his ruleset, define the dependancies.
Even within the constraints of CML1, you can do stuff like "I want
CONFIG_USB_HID, which implies that CONFIG_INPUT is needed"
That simple stuff. For anything beyond that, like "create me an
ipv6-netlink configuration with adequate support for 3rd party modules"
it's not gonna cut it, nor will any reasonable config system.
> > > 3. if it handles #2 what does it do if you turn off that feature again
> > > (CML2 turns off anything it turned on to support that feature, assuming
> > > nothing else needs it)
> >
> > This is a policy decision. I'm not sure one -wants- to do this...
> > Doing something like this blindly can have unintended side effects, i.e.
> > violate the Principle of Least Surprise.
>
> I'll argue that _not_ doing this violated the principle of lease surprise,
> if you turn a feature on and immediatly back off why should anything in
> your config be any different then it was before you turned it on?
It sounds like you want an implementation detail -- undo last [n]
choice[s].
Imagine this case:
make xconfig # select CONFIG_USB_HID, which auto-selects CONFIG_INPUT
{ time passes }
make xconfig # de-select CONFIG_USB_HID
On the second 'make xconfig', should CONFIG_INPUT be automatically
de-selected? No. Because that is making the assumption that the person
does not want to continue to make the input API available.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
> > 2. does it handle the 'I want this feature, turn on everything I need for
> > it'?
>
> This is fundamentally impossible for anything beyond the most simple
> features. Although you can do a lot with config.in info, "everything I
> need" is something a human needs to define in many cases.
You can do that with CML1 or his code. The problem is that you need to
go back through checking with the user because
- Some requirements are going to suprise and may stop other
settings
(Simple example "I want GMX2000 support" -> requires DRM 4.0
DRM 4.0 requires they turn off some DRM 4.1 stuff they selected
- Some have alternate solutions
But you can deduce what to ask the user
Alan Cox wrote:
>
> > > 2. does it handle the 'I want this feature, turn on everything I need for
> > > it'?
> >
> > This is fundamentally impossible for anything beyond the most simple
> > features. Although you can do a lot with config.in info, "everything I
> > need" is something a human needs to define in many cases.
>
> You can do that with CML1 or his code. The problem is that you need to
> go back through checking with the user because
I think I am stumbling over semantics... I know you can turn on needed
stuff when you say "I want CONFIG_USB_HID",
but "I want this feature, turn on everything I need" sounded to me more
like autoconfigurator-type stuff, which is guessing at best.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
David Lang wrote:
>>David Lang wrote:
>>
>>>2. does it handle the 'I want this feature, turn on everything I need for
>>>it'?
>>>
>>>3. if it handles #2 what does it do if you turn off that feature again
>>>(CML2 turns off anything it turned on to support that feature, assuming
>>>nothing else needs it)
>
> #3 may be, but #2 isn't possible if the language doesn't provide enough
> info for the tool to know what is needed to make a feature work.
Ok. I agree, #2 is also a configuration language item.
(actual CML doesn't support #2).
It seems that actual language support #2:
you see that every symbol have a list of dependencies,
so a configuration tools can change these dependencies.
But also CML2 don't support #2 for strange/complex rules (<1%).
(It complains about unmet dependencies.) and we should
not support it for such rules (i.e. if a rules conflicts
with PCI or other rules that force BIG changes...).
giacomo
Giacomo Catenazzi wrote:
> But for kernel/, arch/ there are no simple way to tell:
> "this makefile rule belong to this configuration".
Sure you can. You can generate makefiles from any source you wish...
kernel/* and mm/* are actually easy examples, arch/* is much more
difficult.
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
Hi,
On Thu, 21 Feb 2002, Giacomo Catenazzi wrote:
> How is the actual symbol range?
>
> CONFIG_FOO:
> dep: (FREE? && BEER?)
>
> how you tell configuration rools that
> FOO can be only min/max of (FREE? && BEER?)
I'm not sure I understand you correctly, but the symbol range in this
example would be from 'n' to min(FREE, BEER).
> I mean: Do you use pythons mode to tell when a
> help description end (no tab: new symbol), few spaces:
> is symbol help or configuration symbols)
There is no new config specification yet, I just dump the information in
the database in a somewhat readable format.
bye, Roman
Hi,
On Thu, 21 Feb 2002, David Lang wrote:
As Jeff already correctly said, I only have a converter that takes the
cml1 data and just outputs it into something different.
> 1. does this handle the cross directory dependancies?
The tool records all dependencies independent of the directory.
> 2. does it handle the 'I want this feature, turn on everything I need for
> it'?
>
> 3. if it handles #2 what does it do if you turn off that feature again
> (CML2 turns off anything it turned on to support that feature, assuming
> nothing else needs it)
If you know the dependencies, it's not really difficult to implement this
as far as it's possible.
bye, Roman
Jeff Garzik wrote:
> David Lang wrote:
>> I'll argue that _not_ doing this violated the principle of lease surprise,
>> if you turn a feature on and immediatly back off why should anything in
>> your config be any different then it was before you turned it on?
>
> Imagine this case:
>
> make xconfig # select CONFIG_USB_HID, which auto-selects CONFIG_INPUT
> { time passes }
> make xconfig # de-select CONFIG_USB_HID
>
> On the second 'make xconfig', should CONFIG_INPUT be automatically
> de-selected? No. Because that is making the assumption that the person
> does not want to continue to make the input API available.
It depends. When CONFIG_USB_HID auto-selected CONFIG_INPUT, did the user
know about it? Or did it just happen automagically behind the scenes? If
it was turned on silently, and the subsequent de-select of
CONFIG_USB_HID silently left CONFIG_INPUT turned on, I'd say that
violates least-surprise.
On the other hand, if turning on CONFIG_USB_HID then prompts "to do
that, I also have to turn on CONFIG_INPUT", i suppose it's ok to leave
CONFIG_INPUT turned on later.
--
Jason Lunz Trellis Network Security
[email protected] http://www.trellisinc.com/
Jason Lunz wrote:
>
> Jeff Garzik wrote:
> > David Lang wrote:
> >> I'll argue that _not_ doing this violated the principle of lease surprise,
> >> if you turn a feature on and immediatly back off why should anything in
> >> your config be any different then it was before you turned it on?
> >
> > Imagine this case:
> >
> > make xconfig # select CONFIG_USB_HID, which auto-selects CONFIG_INPUT
> > { time passes }
> > make xconfig # de-select CONFIG_USB_HID
> >
> > On the second 'make xconfig', should CONFIG_INPUT be automatically
> > de-selected? No. Because that is making the assumption that the person
> > does not want to continue to make the input API available.
>
> It depends. When CONFIG_USB_HID auto-selected CONFIG_INPUT, did the user
> know about it? Or did it just happen automagically behind the scenes? If
> it was turned on silently, and the subsequent de-select of
> CONFIG_USB_HID silently left CONFIG_INPUT turned on, I'd say that
> violates least-surprise.
>
> On the other hand, if turning on CONFIG_USB_HID then prompts "to do
> that, I also have to turn on CONFIG_INPUT", i suppose it's ok to leave
> CONFIG_INPUT turned on later.
You do have a point, because there is a small change that a
configuration symbol can be auto-enabled without prompting.
This is more just standard Unix pragmatism, treating auto-remove
operations with far more caution than auto-enable operations, precisely
for cases like the example one above. Only when one has pretty much
complete control of environment do you want to make the assumption that
a 'remove' op is the perfect complement of the 'add' op.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Thu, 21 Feb 2002, Jeff Garzik wrote:
| For directories like kernel/* and mm/* and arch/*, I imagine that down
| the road we will want kernel.conf and mm.conf too, though right now they
| would probably remain as makefiles...
I agree. I was just looking for linux/kernel/config.in a couple
of days ago.
Instead, I had to look in _many_ arch/<archxxx>/config.in files.
Bah.
--
~Randy
Jeff Garzik wrote:
> Alan Cox wrote:
> > You can do that with CML1 or his code. The problem is that you need to
> > go back through checking with the user because
>
> I think I am stumbling over semantics... I know you can turn on needed
> stuff when you say "I want CONFIG_USB_HID",
> but "I want this feature, turn on everything I need" sounded to me more
> like autoconfigurator-type stuff, which is guessing at best.
To stick with that example: CML1 knows (and tools could use that) that
CONFIG_USB_HID needs CONFIG_INPUT. But CML1 doesn't know that you also
need at a host controller driver (CONFIG_USB_UHCI for example). And
even if the config tool would know, it still wouldn't be able to pick
the correct one ...
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
On Feb 21, 2002 08:21 -0500, Jeff Garzik wrote:
> Erik Andersen wrote:
> > I like this. It's simple, its clean, and it keeps all the
> > information in one spot. I think we can go a bit farther here
> > and add in a list of the .c files that enabling this feature
> > should add to the Makefile (per the current
> > obj-$(CONFIG_FOO) += foo.o
> > stuff in the current Makefile).
>
> Hey, you're skipping ahead to the cool chapters!
>
> Seriously, yep, that's exactly where we eventually want to be: all
> config, makefile, and help text info in one place. To add a new net
> driver, I want to be able to simply add two files, driver.c and
> driver.conf, and be done with it.
...and have the Makefile/config tool slurp up "*.conf" from each directory
so you don't need to patch anything to add a new driver/fs/whatever that
doesn't patch external files...
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/