Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
> Would it make sense to define a new entity called "configmenu" (or something
> else) that is equivalent to menuconfig with the following changes?
>
> * it creates a CM_ variable instead of a CONFIG_ one
> * the CM_ symbols are not available to
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
Would it make sense to define a new entity called configmenu (or something
else) that is equivalent to menuconfig with the following changes?
* it creates a CM_ variable instead of a CONFIG_ one
* the CM_ symbols are not available to
Hi,
On 6/24/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
> > [...]
> > Now all the usb drivers will gain USB as a dependency directly and can't be
> > set to something higher than USB.
>
> Ok, so we
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
> > [...]
> > What you have is tristate depends on bool depends on tristate. The bool
> > between the two tristates "promotes" the first tristate from m to y.
> > [...]
> > Or another way, add the
On Jun 23 2007 02:26, Roman Zippel wrote:
>On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
>> But why? Let it do just one thing, and do it well. Is their
>> any requirement anywhere that requires us to give a dual
>> meaning to these menuconfig objects -- i.e. to also control
>> the inclusion /
On Jun 23 2007 02:26, Roman Zippel wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
But why? Let it do just one thing, and do it well. Is their
any requirement anywhere that requires us to give a dual
meaning to these menuconfig objects -- i.e. to also control
the inclusion / exclusion of
On Sat, 23 Jun 2007, Satyam Sharma wrote:
On 6/23/07, Trent Piepho [EMAIL PROTECTED] wrote:
[...]
What you have is tristate depends on bool depends on tristate. The bool
between the two tristates promotes the first tristate from m to y.
[...]
Or another way, add the dependencies of the
Hi,
On 6/24/07, Trent Piepho [EMAIL PROTECTED] wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
On 6/23/07, Trent Piepho [EMAIL PROTECTED] wrote:
[...]
Now all the usb drivers will gain USB as a dependency directly and can't be
set to something higher than USB.
Ok, so we add this as
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> But why? Let it do just one thing, and do it well. Is their
> any requirement anywhere that requires us to give a dual
> meaning to these menuconfig objects -- i.e. to also control
> the inclusion / exclusion of code from the kernel as well as
>
Hi,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
But why? Let
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have
Hi Roman,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config symbols in the kernel originally did, till
> when these
On Jun 23 2007 02:50, Satyam Sharma wrote:
>
> Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
>
> But I still prefer 2.(b) -- making the config scripts intelligent so that if a
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig
Hi Roman,
On 6/23/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing
I don't
Hi Trent,
On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
[...]
What you have is tristate depends on bool depends on tristate. The bool
between the two tristates "promotes" the first tristate from m to y.
[...]
Or another way, add the dependencies of the menuconfig to the if statement:
On 6/23/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi Jan,
On 6/22/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Jun 22 2007 18:24, Roman Zippel wrote:
> >
> >> There have been discussions to remove the default-ys again, I've sent a
patch
> >> [http://lkml.org/lkml/2007/5/12/216], but
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
This is the same problem I explained before:
Hi Jan,
On 6/22/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jun 22 2007 18:24, Roman Zippel wrote:
>
>> There have been discussions to remove the default-ys again, I've sent a patch
>> [http://lkml.org/lkml/2007/5/12/216], but nothing happened.
>>
>> So, should all affected menuconfigs be
On Jun 22 2007 18:24, Roman Zippel wrote:
>
>> There have been discussions to remove the default-ys again, I've sent a patch
>> [http://lkml.org/lkml/2007/5/12/216], but nothing happened.
>>
>> So, should all affected menuconfigs be transformed into tristates, what
>> do you think, Roman? Let
Hi,
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
> V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the "this
> depends on another symbol [USB] that is modular".
That's not how it works, the enclosed symbols depend now on
V4L_USB_DRIVERS, which is a boolean and it can only have
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> I'm to keep "default y" for the menuconfig items.
>
> Since those don't generate any code (there's no Makefile items
> associated with the menuconfig vars),
I don't know that without checking Makefiles/sources, so I have to assume
it
Am Freitag, 22. Juni 2007 schrieb Mauro Carvalho Chehab:
> Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
> > On Jun 22 2007 15:46, Andreas Herrmann wrote:
> > >Hi,
> > >
> > >I am not sure whether it is related or not
> > >But if you select USB as module but build your v4l_usb driver
On Fri, Jun 22, 2007 at 12:03:19PM -0300, Mauro Carvalho Chehab wrote:
> Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
> > On Jun 22 2007 15:46, Andreas Herrmann wrote:
> > >Hi,
> > >
> > >I am not sure whether it is related or not
> > >But if you select USB as module but build your
Em Sex, 2007-06-22 às 16:27 +0200, Roman Zippel escreveu:
> Hi,
>
> On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
>
> > Hi Roman,
> >
> > Several instabilities on Kconfig started to happen after replacing
> > Kconfig menus to use menuconfig, as this one, reported by Oliver:
> >
> > Em Qui,
On Jun 22 2007 16:27, Roman Zippel wrote:
>
>> In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
>> that depends, in turn, on USB. So, if USB is not selected,
>> V4L_USB_DRIVERS should be unselected, unselecting zc0301.
>>
>> Unfortunately, the Kernel building system is not
Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
> On Jun 22 2007 15:46, Andreas Herrmann wrote:
> >Hi,
> >
> >I am not sure whether it is related or not
> >But if you select USB as module but build your v4l_usb driver
> >into the kernel you also get compile errors.
> >Attached is a
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
>
> Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> > Am Donnerstag, 21.
On Fri, Jun 22, 2007 at 03:51:34PM +0200, Jan Engelhardt wrote:
>
> On Jun 22 2007 15:46, Andreas Herrmann wrote:
> >Hi,
> >
> >I am not sure whether it is related or not
> >But if you select USB as module but build your v4l_usb driver
> >into the kernel you also get compile errors.
> >Attached
On Jun 22 2007 15:46, Andreas Herrmann wrote:
>Hi,
>
>I am not sure whether it is related or not
>But if you select USB as module but build your v4l_usb driver
>into the kernel you also get compile errors.
>Attached is a patch which will prevent this by changing the menuconfig
>from bool to
On Fri, Jun 22, 2007 at 10:22:46AM -0300, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
>
> Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> > Am
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster:
> > Right, but IMHO this issue is
On Fri, Jun 22, 2007 at 10:22:46AM -0300, Mauro Carvalho Chehab wrote:
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
Am Donnerstag,
On Jun 22 2007 15:46, Andreas Herrmann wrote:
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
into the kernel you also get compile errors.
Attached is a patch which will prevent this by changing the menuconfig
from bool to tristate.
A
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster:
Right, but IMHO this issue is typical
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
Am Donnerstag, 21. Juni 2007
On Fri, Jun 22, 2007 at 03:51:34PM +0200, Jan Engelhardt wrote:
On Jun 22 2007 15:46, Andreas Herrmann wrote:
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
into the kernel you also get compile errors.
Attached is a patch
Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
On Jun 22 2007 15:46, Andreas Herrmann wrote:
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
into the kernel you also get compile errors.
Attached is a patch which will
On Jun 22 2007 16:27, Roman Zippel wrote:
In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS,
that depends, in turn, on USB. So, if USB is not selected,
V4L_USB_DRIVERS should be unselected, unselecting zc0301.
Unfortunately, the Kernel building system is not properly
Em Sex, 2007-06-22 às 16:27 +0200, Roman Zippel escreveu:
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às
Am Freitag, 22. Juni 2007 schrieb Mauro Carvalho Chehab:
Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
On Jun 22 2007 15:46, Andreas Herrmann wrote:
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
into the
On Fri, Jun 22, 2007 at 12:03:19PM -0300, Mauro Carvalho Chehab wrote:
Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu:
On Jun 22 2007 15:46, Andreas Herrmann wrote:
Hi,
I am not sure whether it is related or not
But if you select USB as module but build your v4l_usb driver
On Jun 22 2007 18:24, Roman Zippel wrote:
There have been discussions to remove the default-ys again, I've sent a patch
[http://lkml.org/lkml/2007/5/12/216], but nothing happened.
So, should all affected menuconfigs be transformed into tristates, what
do you think, Roman? Let me know so I
Hi,
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the this
depends on another symbol [USB] that is modular.
That's not how it works, the enclosed symbols depend now on
V4L_USB_DRIVERS, which is a boolean and it can only have two
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
I'm to keep default y for the menuconfig items.
Since those don't generate any code (there's no Makefile items
associated with the menuconfig vars),
I don't know that without checking Makefiles/sources, so I have to assume
it may
Hi Jan,
On 6/22/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 22 2007 18:24, Roman Zippel wrote:
There have been discussions to remove the default-ys again, I've sent a patch
[http://lkml.org/lkml/2007/5/12/216], but nothing happened.
So, should all affected menuconfigs be
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
This is the same problem I explained before:
On 6/23/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Jan,
On 6/22/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 22 2007 18:24, Roman Zippel wrote:
There have been discussions to remove the default-ys again, I've sent a
patch
[http://lkml.org/lkml/2007/5/12/216], but nothing
Hi Trent,
On 6/23/07, Trent Piepho [EMAIL PROTECTED] wrote:
[...]
What you have is tristate depends on bool depends on tristate. The bool
between the two tristates promotes the first tristate from m to y.
[...]
Or another way, add the dependencies of the menuconfig to the if statement:
diff -r
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
given menuconfig FOO depends on BAR, then all the config BAZs
inside this menuconfig also automatically depend on BAR too.
This is simpler in the long run because it requires least amount
(actually none) of redundant typing
I don't like this, as
Hi Roman,
On 6/23/07, Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
given menuconfig FOO depends on BAR, then all the config BAZs
inside this menuconfig also automatically depend on BAR too.
This is simpler in the long run because it requires least
On Jun 23 2007 02:50, Satyam Sharma wrote:
Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-)
But I still prefer 2.(b) -- making the config scripts intelligent so that if a
given menuconfig FOO depends on BAR, then all the config BAZs
inside this menuconfig also
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
menuconfig is really a type of config symbol, rather than a type of menu.
Well, I'd have to disagree here. A config symbol has code associated
with it (at least _all_ config symbols in the kernel originally did, till
when these menuconfig
Hi Roman,
On 6/23/07, Roman Zippel [EMAIL PROTECTED] wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
menuconfig is really a type of config symbol, rather than a type of menu.
Well, I'd have to disagree here. A config symbol has code associated
with it (at least _all_ config symbols in
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
1. Kconfig symbols will always have code associated with them.
That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have any
Hi,
On 6/23/07, Roman Zippel [EMAIL PROTECTED] wrote:
On Sat, 23 Jun 2007, Satyam Sharma wrote:
1. Kconfig symbols will always have code associated with them.
That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
Yup, so how / why am I wrong? I was making the point that a
menuconfig does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe
Hi,
On 6/23/07, Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
Yup, so how / why am I wrong? I was making the point that a
menuconfig does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
But why? Let it do
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
But why? Let it do just one thing, and do it well. Is their
any requirement anywhere that requires us to give a dual
meaning to these menuconfig objects -- i.e. to also control
the inclusion / exclusion of code from the kernel as well as
also
62 matches
Mail list logo
