* [PATCH] new kconfig goodies
@ 2003-05-12 13:39 Roman Zippel
2003-05-12 14:16 ` Adrian Bunk
` (4 more replies)
0 siblings, 5 replies; 18+ messages in thread
From: Roman Zippel @ 2003-05-12 13:39 UTC (permalink / raw)
To: linux-kernel
Hi,
There is a new kconfig patch at
http://www.xs4all.nl/~zippel/lc/patches/kconfig-2.5.69.diff.gz
It adds a few new features, which were requested a few times:
- ability to force the value of a config symbol
- defaults accept now an expression
- easier way to define derived symbols
- support for ranges
BTW this clears my todo list of important features for the kconfig syntax
itself, if you think there is something missing, please tell me now,
otherwise it might have to wait for 2.7. After this I work a bit more on
xconfig and the library interface.
The changes in detail:
1. Working with derived symbols becomes simpler, e.g. this:
config FS_MBCACHE
tristate
depends on EXT2_FS_XATTR || EXT3_FS_XATTR
default y if EXT2_FS=y || EXT3_FS=y
default m if EXT2_FS=m || EXT3_FS=m
can now also be written as:
config FS_MBCACHE
def_tristate EXT2_FS || EXT3_FS
depends on EXT2_FS_XATTR || EXT3_FS_XATTR
There are two new keywords "def_bool" and "def_tristate", which behave
like "default", except that they also set the type of the config symbol.
Defaults also accept expressions now, the result of it will be used as
default (this works of course only with boolean and tristate symbols).
2. There is a new keyword "enable", which can be used to force the value
of another config value, e.g.
config NLS
bool
depends on JOLIET || FAT_FS || NTFS_FS || NCPFS_NLS || SMB_NLS || JFS_FS || CIFS || BEFS_FS
default y
this could be written as:
config NLS
def_bool JOLIET || FAT_FS || NTFS_FS || NCPFS_NLS || SMB_NLS || JFS_FS || CIFS || BEFS_FS
but this is now possible as well:
config NLS
bool
config JOLIET
bool "Microsoft Joliet CDROM extensions"
enable NLS
config FAT_FS
tristate "DOS FAT fs support"
enable NLS
...
This means the information that a file system needs NLS is now specified
with the file system itself and if the file system is selected, so is NLS.
Another example:
config AGP
tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
default y if GART_IOMMU
this can be changed into:
config AGP
tristate "/dev/agpgart (AGP Support)"
config GART_IOMMU
bool "IOMMU support"
enable AGP
This will cause AGP to be selected if GART_IOMMU is selected.
To better understand how this new feature works, it might help to describe
how a config value is calculated:
config value = (user input && visibility) || reverse dependency
Visibility are the normal dependencies and limit the maximum value a user
can select. Reverse dependencies on the other hand limit the minimum value
a user can select. In above example this means there is a reverse
dependency of GART_IOMMU added to AGP, so that value of AGP cannot be less
than GART_IOMMU anymore.
This feature can be easily abused, so please use it with care, don't use
it to take the choice away from user, e.g. only enable another subsystem
if it would result in compile errors otherwise. If you're not sure, just
ask. To avoid bigger mistakes I finally added the code to check for
recursive dependencies.
3. Finally I added support for ranges, so that this becomes possible:
config LOG_BUF_SHIFT
int "Kernel log buffer size" if DEBUG_KERNEL
range 10 20
...
Right now this is only used to check the direct user input, this means
directly editing .config will ignore the range (please don't rely on this
feature :) ).
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
@ 2003-05-12 14:16 ` Adrian Bunk
2003-05-12 15:37 ` Roman Zippel
2003-05-12 14:32 ` Dave Jones
` (3 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: Adrian Bunk @ 2003-05-12 14:16 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
> Hi,
Hi Roman,
>...
> BTW this clears my todo list of important features for the kconfig syntax
> itself, if you think there is something missing, please tell me now,
> otherwise it might have to wait for 2.7. After this I work a bit more on
> xconfig and the library interface.
>...
there's one feature I'd like to see (I don't see an easy way to achieve
it currently):
A choice with the possibility to select one or more entries, to support
things like:
Supported processors:
[ ] 386
[ ] 486
[ ] 586
...
It should be possible to select more than one item but selecting zero
items should be illegal.
> bye, Roman
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 14:16 ` Adrian Bunk
@ 2003-05-12 15:37 ` Roman Zippel
0 siblings, 0 replies; 18+ messages in thread
From: Roman Zippel @ 2003-05-12 15:37 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
Hi,
On Mon, 12 May 2003, Adrian Bunk wrote:
> A choice with the possibility to select one or more entries, to support
> things like:
> Supported processors:
> [ ] 386
> [ ] 486
> [ ] 586
> ...
>
> It should be possible to select more than one item but selecting zero
> items should be illegal.
I think that has to wait, supporting this properly would require too many
changes and there are other ways to achieve almost the same.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
2003-05-12 14:16 ` Adrian Bunk
@ 2003-05-12 14:32 ` Dave Jones
2003-05-12 15:39 ` Roman Zippel
2003-05-12 16:00 ` Tomas Szepe
2003-05-12 15:13 ` Geert Uytterhoeven
` (2 subsequent siblings)
4 siblings, 2 replies; 18+ messages in thread
From: Dave Jones @ 2003-05-12 14:32 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
> config AGP
> tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
> default y if GART_IOMMU
>
> this can be changed into:
>
> config AGP
> tristate "/dev/agpgart (AGP Support)"
>
> config GART_IOMMU
> bool "IOMMU support"
> enable AGP
>
> This will cause AGP to be selected if GART_IOMMU is selected.
Looks good. However, will this still offer the CONFIG_AGP tristate
in the menu? If IOMMU is on, there must be no way to switch off
the agpgart support on which it depends.
Dave
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 14:32 ` Dave Jones
@ 2003-05-12 15:39 ` Roman Zippel
2003-05-12 16:08 ` Dave Jones
2003-05-12 16:00 ` Tomas Szepe
1 sibling, 1 reply; 18+ messages in thread
From: Roman Zippel @ 2003-05-12 15:39 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
Hi,
On Mon, 12 May 2003, Dave Jones wrote:
> > config AGP
> > tristate "/dev/agpgart (AGP Support)"
> >
> > config GART_IOMMU
> > bool "IOMMU support"
> > enable AGP
> >
> > This will cause AGP to be selected if GART_IOMMU is selected.
>
> Looks good. However, will this still offer the CONFIG_AGP tristate
> in the menu? If IOMMU is on, there must be no way to switch off
> the agpgart support on which it depends.
Yes, you will see AGP, but you can't change it.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 15:39 ` Roman Zippel
@ 2003-05-12 16:08 ` Dave Jones
0 siblings, 0 replies; 18+ messages in thread
From: Dave Jones @ 2003-05-12 16:08 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
On Mon, May 12, 2003 at 05:39:45PM +0200, Roman Zippel wrote:
> > Looks good. However, will this still offer the CONFIG_AGP tristate
> > in the menu? If IOMMU is on, there must be no way to switch off
> > the agpgart support on which it depends.
>
> Yes, you will see AGP, but you can't change it.
Perfect!
Dave
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 14:32 ` Dave Jones
2003-05-12 15:39 ` Roman Zippel
@ 2003-05-12 16:00 ` Tomas Szepe
2003-05-12 22:36 ` Roman Zippel
1 sibling, 1 reply; 18+ messages in thread
From: Tomas Szepe @ 2003-05-12 16:00 UTC (permalink / raw)
To: Dave Jones, Roman Zippel, linux-kernel
> [davej@codemonkey.org.uk]
>
> On Mon, May 12, 2003 at 03:39:11PM +0200, Roman Zippel wrote:
>
> > config AGP
> > tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
> > default y if GART_IOMMU
> >
> > this can be changed into:
> >
> > config AGP
> > tristate "/dev/agpgart (AGP Support)"
> >
> > config GART_IOMMU
> > bool "IOMMU support"
> > enable AGP
> >
> > This will cause AGP to be selected if GART_IOMMU is selected.
>
> Looks good. However, will this still offer the CONFIG_AGP tristate
> in the menu? If IOMMU is on, there must be no way to switch off
> the agpgart support on which it depends.
Also, will the config system let the user know that their having
enabled a certain option has affected other options (possibly in
different submenus)? As things work now, there's no way to tell
if an option has been switched on "by dependency," so in the above
example, in switching GART_IOMMU off after its switching on has
enabled AGP, the system won't know to disable AGP again. I'm not
convinced this is a nice feature in fact. :) Maybe we just need
something like grayed-out entries with a comment, for instance:
/* [ ] IOMMU support (needs "/dev/agpgard (AGP Support)") */
--
Tomas Szepe <szepe@pinerecords.com>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 16:00 ` Tomas Szepe
@ 2003-05-12 22:36 ` Roman Zippel
0 siblings, 0 replies; 18+ messages in thread
From: Roman Zippel @ 2003-05-12 22:36 UTC (permalink / raw)
To: Tomas Szepe; +Cc: Dave Jones, linux-kernel
Hi,
On Mon, 12 May 2003, Tomas Szepe wrote:
> Also, will the config system let the user know that their having
> enabled a certain option has affected other options (possibly in
> different submenus)?
The user will see that he can't disable certain options.
This is basically the same problem as with other dependencies, if the user
selects an option other options may become visible. There is no direct
information, how the config option depend on each other (except xconfig
offers that as a debug option).
> As things work now, there's no way to tell
> if an option has been switched on "by dependency," so in the above
> example, in switching GART_IOMMU off after its switching on has
> enabled AGP, the system won't know to disable AGP again. I'm not
> convinced this is a nice feature in fact. :) Maybe we just need
> something like grayed-out entries with a comment, for instance:
>
> /* [ ] IOMMU support (needs "/dev/agpgard (AGP Support)") */
Of course the same can be done with normal dependencies, but this new
option offers more flexibility. Important options don't have to be hidden
away behind a lot of dependencies. I'm aware that this can be abused, so I
have to watch a bit how it will be used.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
2003-05-12 14:16 ` Adrian Bunk
2003-05-12 14:32 ` Dave Jones
@ 2003-05-12 15:13 ` Geert Uytterhoeven
2003-05-12 15:43 ` Roman Zippel
2003-05-13 1:38 ` Miles Bader
2003-05-13 1:44 ` Miles Bader
4 siblings, 1 reply; 18+ messages in thread
From: Geert Uytterhoeven @ 2003-05-12 15:13 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linux Kernel Development
On Mon, 12 May 2003, Roman Zippel wrote:
> 3. Finally I added support for ranges, so that this becomes possible:
>
> config LOG_BUF_SHIFT
> int "Kernel log buffer size" if DEBUG_KERNEL
> range 10 20
> ...
>
> Right now this is only used to check the direct user input, this means
> directly editing .config will ignore the range (please don't rely on this
> feature :) ).
I hope `make oldconfig' also checks the range? Imagine ranges being changed in
the Kconfig file.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 15:13 ` Geert Uytterhoeven
@ 2003-05-12 15:43 ` Roman Zippel
0 siblings, 0 replies; 18+ messages in thread
From: Roman Zippel @ 2003-05-12 15:43 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Kernel Development
Hi,
On Mon, 12 May 2003, Geert Uytterhoeven wrote:
> > Right now this is only used to check the direct user input, this means
> > directly editing .config will ignore the range (please don't rely on this
> > feature :) ).
>
> I hope `make oldconfig' also checks the range? Imagine ranges being changed in
> the Kconfig file.
It's basically the same problem, everything that comes from .config is not
checked yet, but it's easy to change though.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
` (2 preceding siblings ...)
2003-05-12 15:13 ` Geert Uytterhoeven
@ 2003-05-13 1:38 ` Miles Bader
2003-05-13 1:44 ` Miles Bader
4 siblings, 0 replies; 18+ messages in thread
From: Miles Bader @ 2003-05-13 1:38 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
Roman Zippel <zippel@linux-m68k.org> writes:
> 2. There is a new keyword "enable", which can be used to force the value
> of another config value, e.g.
Excellent, excellent, excellent!
I think many patches will now interfere with each other less...
-Miles
--
I'd rather be consing.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
` (3 preceding siblings ...)
2003-05-13 1:38 ` Miles Bader
@ 2003-05-13 1:44 ` Miles Bader
2003-05-13 15:27 ` Roman Zippel
4 siblings, 1 reply; 18+ messages in thread
From: Miles Bader @ 2003-05-13 1:44 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
Roman Zippel <zippel@linux-m68k.org> writes:
> BTW this clears my todo list of important features for the kconfig syntax
> itself, if you think there is something missing, please tell me now,
> otherwise it might have to wait for 2.7.
Hi, I sent the following about kconfig a while ago, but never got an
answer; do you have any comment on it?
Here's the message:
> I have the following two entries in my Kconfig file (arch/v850/Kconfig):
>
> config RTE_CB_MULTI
> bool
> # RTE_CB_NB85E can either have multi ROM support or not, but
> # other platforms (currently only RTE_CB_MA1) require it.
> prompt "Multi monitor ROM support" if RTE_CB_NB85E
> depends RTE_CB
> default y
>
> config RTE_CB_MULTI_DBTRAP
> bool "Pass illegal insn trap / dbtrap to kernel"
> depends RTE_CB_MULTI
> default n
>
> What I expect this to do is to only ask the first question (RTE_CB_MULTI)
> if RTE_CB_NB85E is true and otherwise just assume true -- this part
> seems to work correctly -- but to _always_ ask the second question
> (RTE_CB_MULTI_DBTRAP) as long as its dependencies are true.
>
> However, what happens in practice is that the second question is only
> displayed if the first question is displayed (the resulting actual value
> of RTE_CB_MULTI_DBTRAP is whatever value it had before I entered the
> menuconfig).
>
> So... is this a bug? If not, is there some other way I can have a
> question [a] depend on another question [b], where [b] is optional
> (defaulting to y), but [a] is not?
[I haven't tested this recently, so I suppose it could have silently
been fixed.]
Thanks,
-Miles
--
Would you like fries with that?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-13 1:44 ` Miles Bader
@ 2003-05-13 15:27 ` Roman Zippel
2003-05-13 21:17 ` Miles Bader
0 siblings, 1 reply; 18+ messages in thread
From: Roman Zippel @ 2003-05-13 15:27 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
Hi,
On 13 May 2003, Miles Bader wrote:
> > I have the following two entries in my Kconfig file (arch/v850/Kconfig):
> >
> > config RTE_CB_MULTI
> > bool
> > # RTE_CB_NB85E can either have multi ROM support or not, but
> > # other platforms (currently only RTE_CB_MA1) require it.
> > prompt "Multi monitor ROM support" if RTE_CB_NB85E
> > depends RTE_CB
> > default y
> >
> > config RTE_CB_MULTI_DBTRAP
> > bool "Pass illegal insn trap / dbtrap to kernel"
> > depends RTE_CB_MULTI
> > default n
> >
> > What I expect this to do is to only ask the first question (RTE_CB_MULTI)
> > if RTE_CB_NB85E is true and otherwise just assume true -- this part
> > seems to work correctly -- but to _always_ ask the second question
> > (RTE_CB_MULTI_DBTRAP) as long as its dependencies are true.
With the new patch this will work. The effect is basically the same as if
you would add "enable RTE_CB_MULTI" to RTE_CB_MA1 - RTE_CB_MULTI is
visible but you cannot change it.
BTW you can remove the "default n" line, this is the default anyway, so
it has no effect.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-13 15:27 ` Roman Zippel
@ 2003-05-13 21:17 ` Miles Bader
2003-05-14 19:51 ` Roman Zippel
0 siblings, 1 reply; 18+ messages in thread
From: Miles Bader @ 2003-05-13 21:17 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
On Tue, May 13, 2003 at 05:27:30PM +0200, Roman Zippel wrote:
> With the new patch this will work. The effect is basically the same as if
> you would add "enable RTE_CB_MULTI" to RTE_CB_MA1 - RTE_CB_MULTI is
> visible but you cannot change it.
I see.
BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
forces the depends to be y, but not that it also forces the _value_.
Why not have two:
enable FOO - forces the `depends' value of FOO to y
but it will still prompt
force FOO - forces both the `depends' and value of FOO to y
prompting for FOO is turned off
-Miles
--
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-13 21:17 ` Miles Bader
@ 2003-05-14 19:51 ` Roman Zippel
2003-05-14 20:56 ` Andreas Schwab
0 siblings, 1 reply; 18+ messages in thread
From: Roman Zippel @ 2003-05-14 19:51 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
Hi,
On Tue, 13 May 2003, Miles Bader wrote:
> BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
> forces the depends to be y, but not that it also forces the _value_.
>
> Why not have two:
>
> enable FOO - forces the `depends' value of FOO to y
> but it will still prompt
> force FOO - forces both the `depends' and value of FOO to y
> prompting for FOO is turned off
I don't really like "force", it's IMO a bit too strong and too unspecific
(although enable is here only a bit better). The first I'd rather call
"visible", but I don't see a need for this and I wouldn't immediately know
how to support this, a config entry can have multiple prompts and every
prompt has its own dependencies, so which one should I enable? It would
probably be easier to enable/force the dependencies so the prompt becomes
visible.
But I'm open to suggestions for a better name, "select" might be a good
alternative. Other ideas? Opinions?
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-14 19:51 ` Roman Zippel
@ 2003-05-14 20:56 ` Andreas Schwab
2003-05-14 22:11 ` Roman Zippel
0 siblings, 1 reply; 18+ messages in thread
From: Andreas Schwab @ 2003-05-14 20:56 UTC (permalink / raw)
To: Roman Zippel; +Cc: Miles Bader, linux-kernel
Roman Zippel <zippel@linux-m68k.org> writes:
|> Hi,
|>
|> On Tue, 13 May 2003, Miles Bader wrote:
|>
|> > BTW, the name `enable' seems to be a misnomer -- `enable' implies that it
|> > forces the depends to be y, but not that it also forces the _value_.
|> >
|> > Why not have two:
|> >
|> > enable FOO - forces the `depends' value of FOO to y
|> > but it will still prompt
|> > force FOO - forces both the `depends' and value of FOO to y
|> > prompting for FOO is turned off
|>
|> I don't really like "force", it's IMO a bit too strong and too unspecific
|> (although enable is here only a bit better). The first I'd rather call
|> "visible", but I don't see a need for this and I wouldn't immediately know
|> how to support this, a config entry can have multiple prompts and every
|> prompt has its own dependencies, so which one should I enable? It would
|> probably be easier to enable/force the dependencies so the prompt becomes
|> visible.
|>
|> But I'm open to suggestions for a better name, "select" might be a good
|> alternative. Other ideas? Opinions?
How about "override"?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-14 20:56 ` Andreas Schwab
@ 2003-05-14 22:11 ` Roman Zippel
2003-05-15 0:21 ` Michael Alan Dorman
0 siblings, 1 reply; 18+ messages in thread
From: Roman Zippel @ 2003-05-14 22:11 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Miles Bader, linux-kernel
Hi,
On Wed, 14 May 2003, Andreas Schwab wrote:
> |> But I'm open to suggestions for a better name, "select" might be a good
> |> alternative. Other ideas? Opinions?
>
> How about "override"?
Hmm, I think it doesn't really fit, it's a bit more than this, e.g. if one
option is set 'm', the other option can still be set to 'm' or 'y'. The
logic is basically "if this option is selected, automatically select this
other option too.", so currently I like "select" best.
bye, Roman
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] new kconfig goodies
2003-05-14 22:11 ` Roman Zippel
@ 2003-05-15 0:21 ` Michael Alan Dorman
0 siblings, 0 replies; 18+ messages in thread
From: Michael Alan Dorman @ 2003-05-15 0:21 UTC (permalink / raw)
To: linux-kernel
Roman Zippel <zippel@linux-m68k.org> writes:
> Hmm, I think it doesn't really fit, it's a bit more than this, e.g. if one
> option is set 'm', the other option can still be set to 'm' or 'y'. The
> logic is basically "if this option is selected, automatically select this
> other option too.", so currently I like "select" best.
How about 'assert'?
Mike
--
I don't need no makeup, I've got real scars -- Tom Waits
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-05-15 0:24 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-12 13:39 [PATCH] new kconfig goodies Roman Zippel
2003-05-12 14:16 ` Adrian Bunk
2003-05-12 15:37 ` Roman Zippel
2003-05-12 14:32 ` Dave Jones
2003-05-12 15:39 ` Roman Zippel
2003-05-12 16:08 ` Dave Jones
2003-05-12 16:00 ` Tomas Szepe
2003-05-12 22:36 ` Roman Zippel
2003-05-12 15:13 ` Geert Uytterhoeven
2003-05-12 15:43 ` Roman Zippel
2003-05-13 1:38 ` Miles Bader
2003-05-13 1:44 ` Miles Bader
2003-05-13 15:27 ` Roman Zippel
2003-05-13 21:17 ` Miles Bader
2003-05-14 19:51 ` Roman Zippel
2003-05-14 20:56 ` Andreas Schwab
2003-05-14 22:11 ` Roman Zippel
2003-05-15 0:21 ` Michael Alan Dorman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).