> > I would define three basic types: integer,
> > string, and undefined. Booleans (and tri-states) are synonmous with
> > strings. All comperiasons involving undefined varibles are false (breaking
> > !(a!=b) being equivelent to a=b, but that is fairly normal). Between their
> > first mention (including in a dependincy) and when they are assigned a
> > value, all varibles are undefined.
> No, undefined is not a type, it is a variable attribute. A variable of
> any type can be defined or undefined.
But when a varible in undefined, it dosn't yet have a type either, so we
can't talk about a type other then undefined. In this case, I think it is
cleaner to think of undefined as a type... possibly. Think of a varible as
being a bit and a pointer. The bit specifies whether we are talking of an
integer or a string, and the pointer is for the data: NULL for undefined,
else the value after cannonisation (convert trinary to lowercase, strip
insignifacant zeros on ints, but don't convert base -- it's cleaner to keep
it as entered and convert on compare.) There isn't a need to tell the
difference between strings and trinary.
> > Such
> > usages should be hunt down and shot...
[...]
> > See the attached patch (vs. 2.1.87).
> > (OK, this message is getting to long, so it is as a sepperate posting.)
> I totally agree with this patch.
It's about time I make a non-buggy patch! <G>
> No. If the variable is not defined in defconfig, it is _undefined_. It has
> no value, and having no value is different of having the value ""
>
> config, menuconfig, _and_ xconfig will take the value as being undefined,
> because they are _scripts_. That's why we can have problems with tests
> like if [ "$CONFIG_FOO" != " ]; because in this case, the test is true
> when the variable is undefined !
Hmm? That's why I suguested always-false semantics for undefined. But I
was wrong. What I want is that (where UNDEF is undefined) CONFIG_FOO = y is
false, but CONFIG_FOO != n is true, which is exactly the normal way. My
bad... That's what you get for doing this at two in the morning, I guess...
<G>.
> > I think that the autoconf.h writing program should remain sepperate from the
> > .config writer...
> AFAK, it is now currently separated. It is generated by config/menuconfig
> and xconfig, so I see no reason why the library could not handle it.
The library could handle it -- I just want to make certian that the
autoconf.h file remains made from the .config file, and that the "current
values" are taken from the .config file -- otherwise, the "edit .config and
run 'make oldconfig'" method fails, and that's the True Hacker's way of
doing it. <G>
> > I see no compeling reason to merge them... for one thing,
> > the .config file is ment to be human-readable and modifible. If we merge,
> > then that is in some jeporday.
> I don't want to merge, I just want to have the library providing two
> services : one is the generation of a .config, and the other is the
> generation of an autoconf.h
How is that not merging? Then again, I was wrong on what I thought the
current method was... I need to read up on this stuff.
> > > II.1.2 second round
> > > Change the syntax, that will be transparent for all back-ends, thanks to
> > > our parsing library.
> > Why are we checking that all [Cc]onfig.ins are compliant to the old standard
> > before upgrading all of them to the new synthax?
> MEC has a good answer for that: because it is very difficult to do a huge
> modification of such a fundamental thing (without this tools, it is very
> hard these day to manage to compile a kernel) in all the existing trees :
> Linus one, davem one, and the mips tree. That's why we need to be
> compatible first.
I think that we are at least compatable across the trees (then again, I
wouldn't know -- I use the Linus tree.) I'm not certain that there is some
language in the config files that isn't strictly compliant with the current
spec (which is all in various people's heads)... but we are going to need to
re-write the [Cc]onfig.in files, all 3228 lines of them (in the linus tree),
so why not go straight from buggy current synthax to new (hopefully) bugless
synthax in one fell swoop?
> > Then again, the includes need to be done AFTER checking if that line should
> > be parsed as in the current system, not before it as in C (the
> > pre-processor, rather).
> Hehe :) You make me smile :) It seems that you have not yet tried to parse
> such a file in C :)
Sorry, that was unclear -- what I ment was somthing like this:
void foo(int a) {
if (a==1)
#include <foo.h>
else
#include <bar.h>
}
We don't want that (IE foo.h and bar.h are always both included).
Conditinal including of config files is neccessary (as parsing the C and
preprocessor at the same time would accomplish)...
if [ "$CONFIG_NET" = "y" ]; then
source net/Config.in
fi
is a very nice construction. So is
<include net/Config.in> CONFIG_NET = y.
On the other hand, having to add a dependance on CONFIG_NET for everyting in
net/Config.in would be ugly. (Then again, we can do that in the libary
implicitly instead of in the config language explicitly.)
> The goal of the game is not to parse the config file
> several times, so you have to parse everything before beginning to work
> with it.
You could simulate re-parsing by adding the dependincies of the include
statment to every statment inside the included file. That's probably the
way to go here.
> > > dep_tristate 'foo' CONFIG_A CONFIG_B == y
> > >
> > > but we could also use
> > >
> > > dep_tristate 'foo' CONFIG_A CONFIG_B != m
> > >
> > > in order to avoid the definition of bogus options like in the sound
> > > driver.
> > Huha? I'm sorry, but that made no sense to me...
> I wanted to write something like
> CONFIG_A
> n
> m CONFIG_MODULE == y
> y CONFIG_B != m
>
> Look at the CONFIG_PARIDE_PARPORT bogus option to have a better
> understanding of the problem.
Ahh... I see. CONFIG_PARIDE I would write like this:
CONFIG_PARIDE
!n # dependant on nothing
y CONFIG_PARPORT = y
y CONFIG_PARPORT = n # don't report any options to the frontend
# untill we are finished considering all of
# them. Just give the go-ahead on "y" if
# either work out, else report it as disabled.
m # implicit dependance on CONFIG_MODULES, but nothing else
<include drivers/block/paride/Config.in> CONFIG_PARIDE=(y||m)
I think that has the same semantics as the current setup...
> > > My library also issue warnings for name that don't begin with CONFIG_
> > I don't think that I like this (for the new synthax, that is)... Being able
> > to do varible substitution for things like MAXIRQ is nice, so I think that
> > not having a "CONFIG_" prefix should just meen that the varible is internal,
> > and shouldn't be writen out to the .config file.
> Right. That's why I just issue a warning, but continues to parse normally.
In the current synthax, that's probably the right thing to do. OTOH, I
think that having a public and private namespace is probably a good thing,
and names lacking a CONFIG_ are a good canidate for private use.
> Agreed. Albert D. Cahalan suggested a good syntax for dependancies
> instead of writing:
>
> CONFIG_A = y -o CONFIG_A = m
>
> we could simply put : CONFIG_A=my
> and identically,
>
> CONFIG_A != n && CONFIG_A != m
>
> could be written like CONFIG_A!=nm
How about CONFIG_A = (y||m)? Just make relational operators distributive
over logical operators (remember, y/n/m != T/F <G>). I don't much like
CONFIG_A=my, as that would refer to the string "my", not two sepperate
possiblities.
> > How about somthing more complex: CONFIG_SB_MPU_IRQ...
> > CONFIG_SB_MPU_IRQ
> > !n CONFIG_SB = y
> > (1-MAXIRQ) CONFIG_SB = y
> >
> > or is this nicer?
> > CONFIG_SB_MPU_IRQ CONFIG_SB=y
> > !n
> > (1-MAXIRQ)
> >
> > This does some more complex stuff... We mix boolean and integer types here,
> I don't like this mix. I don't understand its meaning
> But variable substitution is a good thing
Hmm? Both meen that the options are n (the default), or an integer between
one and MAXINT (the parenthises are to sepperate it from the string
"1-MAXIRQ"). Make CONFIG_SB_MPU_IRQ an integer if so tagged, else a
trinary. We only do VERY loose typing of varibles -- enough to know if 16
== 0xF or not.
> > Anybody see problems with this synthax? (Other then that the ! for default
> > looks too much like negation -- anybody with a better idea? It can't be
> > used as a option without messy quoting, and it shouldn't be a commonly-used
> > wildcard character either...)
> You could use § (the paragraph symbol)
But that's hard to type (and shows up on my screen as a line with a little
circle over it -- I need to give this font a unimap)... Sigh -- perhaps "@"?
> > > Menu 'my main menu'
> > > Menu 'title2'
> > > EndMenu
> > > Menu 'title3'
> > > EndMenu
> > > EndMenu
> > Hmm... but what about comments that aren't really a menu-head ("MPU401 IRQ
> > is only required with Jazz16, SM Wave and ESS1688.")
> Of course I keep them, but the interest here is to store the label of a
> menu in its declarattion instead of having to use the next_comment/comment
> stuff.
I like this synthax, though I'd replace the quoted strings with MENU_FOO,
and then drag the line out from Config.help (one per dir, not global). It
makes for easyer translation, I think (by sepperating logic from
presentation).
> > I like just replacing choice lists with single varibles that can take any of
> > a number of values, just like the above:
> > CONFIG_PROCESSOR
> > 386
> > 486
> > 586
> > 686
> Yes, but this is related to the fact that you can do tests on data
> variables. I don't know if it is a good thing. We should keep in mind that
> simplicity is our best friend.
I see three types of varibles (int, string, trinary) as more complex then
two (string, int).
BTW -- Anybody willing to host a mallinglist? I would, but doing it over a
transient x2 line dosn't seem like to hot an idea.
-=- James Mastros
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu