Guys,
Since the old CVS days, the building system for V4L/DVB assumed that all
required kernel dependencies were compiled. This is bad, since some
obsoleted stuff might be required, without need (like, for example, SS
support for saa7134_oss, cx88_oss that were replaced by saa7134_alsa and
cx88_alsa).
With the inclusion of radio devices, some very unusual modules were also
required, to compile miropcm20 (the miro-pcm SS mixer driver).
The proposed patch adds the capability to the building system for it to
check kernel's config.h and autoconf.h at kernel building tree,
identifying all options used during kernel compilation time. Those
options will now be reflected on Kconfig.kern and at make all building.
Please test and give us some feedback.
Cheers,
Mauro.

, here it is the second version of the build patch, fixing some small
stuff on the previous one. Please test. I should apply it tomorrow
nobody complains :)

Em Ter, 2006-06-20 12:23 -0300, Mauro Carvalho Chehab escreveu:
Guys,

Since the old CVS days, the building system for V4L/DVB assumed that all
required kernel dependencies were compiled. This is bad, since some
obsoleted stuff might be required, without need (like, for example, SS
support for saa7134_oss, cx88_oss that were replaced by saa7134_alsa and
cx88_alsa).

With the inclusion of radio devices, some very unusual modules were also
required, to compile miropcm20 (the miro-pcm SS mixer driver).

The proposed patch adds the capability to the building system for it to
check kernel's config.h and autoconf.h at kernel building tree,
identifying all options used during kernel compilation time. Those
options will now be reflected on Kconfig.kern and at make all building.

Please test and give us some feedback.

Cheers,
Mauro.

Em Ter, 2006-06-20 12:23 -0300, Mauro Carvalho Chehab escreveu:
Since the old CVS days, the building system for V4L/DVB assumed that all
required kernel dependencies were compiled. This is bad, since some
obsoleted stuff might be required, without need (like, for example, SS
support for saa7134_oss, cx88_oss that were replaced by saa7134_alsa and
cx88_alsa).

With the inclusion of radio devices, some very unusual modules were also
required, to compile miropcm20 (the miro-pcm SS mixer driver).

The proposed patch adds the capability to the building system for it to
check kernel's config.h and autoconf.h at kernel building tree,

You beat me too it. In fact some of the changes I've been making to the build
system have been aimed at this. There is still a bug with the config-compat.h
file that I was going to fix.

It looks like there is no way to get the old behavior? I think it is
important that there is still a way to build all modules, even if the current
kernel doesn't have ISA support or whatever. It makes it much harder for
developers to do proper testing without this.

Is there a reason that you used the config.h and autoconf.h files? It seems
like it would be much easier to read the kernel's .config file. Since
autoconf.h is generated from .config, it's safe to require that .config be
there, isn't it? Can you even build v4l-dvb if it's not there? I know that
you will get non-fatal errors if $(KDIR)/.config is missing.

It looks like this can't handle all depend lines in v4l-dvb, for example:
depends on VIDEV4L2 && !SPARC32 && !SPARC64
depends on VIDEDEV!=n
depends on RADIZLTRIX=y
depends on DVB_CRE && (PCI || USB) && I2C

The '!' dependencies will be ignored (*). The '=' and '!=' are ignored. The bit
'(PCI || USB)' will be treated as 'USB'.

(*) Not totally. They will be checked to see if they are not 'y' (**), but
they won't appear in Kconfig.kern like they should.

(**) What does 'm' mean in this context? Does it means yes, no, or is the '!'
operator only allowed for booleans and not tristates?

Em Ter, 2006-06-20 15:57 -0700, Trent Piepho escreveu:
Em Ter, 2006-06-20 s 12:23 -0300, Mauro Carvalho Chehab escreveu:
Since the old CVS days, the building system for V4L/DVB assumed that all
required kernel dependencies were compiled. This is bad, since some
obsoleted stuff might be required, without need (like, for example, SS
support for saa7134_oss, cx88_oss that were replaced by saa7134_alsa and
cx88_alsa).

With the inclusion of radio devices, some very unusual modules were also
required, to compile miropcm20 (the miro-pcm SS mixer driver).

The proposed patch adds the capability to the building system for it to
check kernel's config.h and autoconf.h at kernel building tree,

You beat me too it. In fact some of the changes I've been making to the build
system have been aimed at this. There is still a bug with the config-compat.h
file that I was going to fix.
I'm doing some fixes also at Makefile for it to work with 3.81, and I
should post today. This will affect config-compat.h handler, since the
kernel building system auto-generates several makefiles (like, for
example, .flexcop-dma.o.cmd), doing some conflicts with config-compat.h
rule.

It looks like there is no way to get the old behavior? I think it is
important that there is still a way to build all modules, even if the current
kernel doesn't have ISA support or whatever. It makes it much harder for
developers to do proper testing without this.
If you don't have all dependencies, building will just fail. Most claims
we currently have about the building system are related to miropcm20.
This piece needs miro oss mixer (SUND_ACI_MIXER), that most people
don't need. We had also to mark at compilation blacklist those modules
like VIN that are used on non-intel architectures, and use
arch-dependent calls.

The alternative for the developers is to look at the dependency check
messages and enable the proper modules at their kernels, like:

VIDEM32R_AR: Required kernel opt 'M32R' is not present
VIDEVIN: Required kernel opt 'I2C_ALGSGI' is not present
VIDEM32R_AR_M64278: Required kernel opt 'VIDEM32R_AR' is not present
VIDEM32R_AR_M64278: Required kernel opt 'PLAT_M32700UT' is not present

So, for example, if I want Vino, I know that I need a SGI platform and
enable I2C_ALGSGI.

Is there a reason that you used the config.h and autoconf.h files? It seems
like it would be much easier to read the kernel's .config file. Since
autoconf.h is generated from .config, it's safe to require that .config be
there, isn't it? Can you even build v4l-dvb if it's not there? I know that
you will get non-fatal errors if $(KDIR)/.config is missing.
Seems safer to trust at the headers, especially for those users that
don't have kernel sources on their machines. It is not hard to read
the .h files, and it also provides an additional info about tri-state
dependencies.

It looks like this can't handle all depend lines in v4l-dvb, for example:
depends on VIDEV4L2 && !SPARC32 && !SPARC64
depends on VIDEDEV!=n
depends on RADIZLTRIX=y
depends on DVB_CRE && (PCI || USB) && I2C

The '!' dependencies will be ignored (*).
See bellow.

The '=' and '!=' are ignored.
True. For the expressions we currently have, it will work fine, but for
sure we should improve expressions handling to cover the entire syntax.
The bit '(PCI || USB)' will be treated as 'USB'.
It will, in fact, require both PCI and USB. Also not really weird.

(*) Not totally. They will be checked to see if they are not 'y' (**), but
they won't appear in Kconfig.kern like they should.

(**) What does 'm' mean in this context? Does it means yes, no, or is the '!'
operator only allowed for booleans and not tristates?
This is a weird behavior of Kbuild: if you negate a tri-state, Y becames
N, but M remains as M, so ! is properly handled [1], since ! operator
will do: 2-/expr/), and, as m=1, 2-1=1.

[1]

Cheers,
Mauro.

Em Ter, 2006-06-20 15:24 -0300, Mauro Carvalho Chehab escreveu:
, here it is the second version of the build patch, fixing some small
stuff on the previous one. Please test. I should apply it tomorrow
nobody complains :)

, patches applied to mainstream. It should generate some warning
messages like this (for make allmodconfig):

VIDEPLANB requires version 2.6.99
VIDEZR36120 requires version 2.6.99
RADIMIRPCM20: Required kernel opt 'SUND_ACI_MIXER' is not present
VIDEM32R_AR: Required kernel opt 'M32R' is not present
VIDEVIN: Required kernel opt 'I2C_ALGSGI' is not present
VIDEM32R_AR_M64278: Required kernel opt 'VIDEM32R_AR' is not present
VIDEM32R_AR_M64278: Required kernel opt 'PLAT_M32700UT' is not present
RADIMIRPCM20_RDS: Required kernel opt 'RADIMIRPCM20' is not
present
VIDEPLANB: Required kernel opt 'PPC_PMAC' is not present

And will disable all the above config stuff. So, only the drivers that
should compile fine with the current kernel configuration will be
selected.

Cheers,
Mauro.

Wed, 21 Jun 2006, Mauro Carvalho Chehab wrote:
You beat me too it. In fact some of the changes I've been making to the build
system have been aimed at this. There is still a bug with the config-compat.h
file that I was going to fix.
I'm doing some fixes also at Makefile for it to work with 3.81, and I
should post today. This will affect config-compat.h handler, since the
kernel building system auto-generates several makefiles (like, for
example, .flexcop-dma.o.cmd), doing some conflicts with config-compat.h
rule.

The config-compat.h problem is still there. Unless you have more fixes for
this that aren't in Hg, I can fix this one.

It looks like there is no way to get the old behavior? I think it is
important that there is still a way to build all modules, even if the current
kernel doesn't have ISA support or whatever. It makes it much harder for
developers to do proper testing without this.
If you don't have all dependencies, building will just fail. Most claims

I can build the radio drivers, even though I have ISA turned off in my
kernel and they all need ISA. I could build and even use cx88-alsa, but
now it's turned off since I build the alsa driver devel tree out of
kernel, and have alsa turned off in the kernel.

I think, there should options to do both:

A. Make all modules my kernel, as configured, can use
B. Make all modules that my kernel can build

B is what was done before, now you can o0Dnly get A. I think you will
find that drivers with extra dependencies on the kernel that most people
don't need will not get tested nearly so much. I have submitted many
fixes for drivers that I don't use. I suppose it would be better, if I
never did that?

like it would be much easier to read the kernel's .config file. Since
autoconf.h is generated from .config, it's safe to require that .config be
there, isn't it? Can you even build v4l-dvb if it's not there? I know that
you will get non-fatal errors if $(KDIR)/.config is missing.
Seems safer to trust at the headers, especially for those users that
don't have kernel sources on their machines. It is not hard to read
the .h files, and it also provides an additional info about tri-state
dependencies.

Is there a reason you don't just read autoconf.h, which doesn't have any
recursive includes to worry about? It has all the config options in it.
The structure of config.h is somewhat more complex, for example the you
will read in asm/kgdb.h because config.h includes it.

BTW, your config.h parser can't handle tabs. You'd be better served if you
used \S, non-whitespace character, in the regular expressions instead of
[^ ]. Also useful is \w, alphanumeric plus "_". There are options in the
kernel that use lowercase letters, which your code can't handle either.

It looks like this can't handle all depend lines in v4l-dvb, for example:
depends on VIDEV4L2 && !SPARC32 && !SPARC64
depends on VIDEDEV!=n
depends on RADIZLTRIX=y
depends on DVB_CRE && (PCI || USB) && I2C

The '!' dependencies will be ignored (*).
See bellow.

They don't work correctly. Look at the Kconfig.kern file, where is
SPARC32 and SPARC64? They don't appear in it at all. They should be
there, either on or off depending on the kernel. You have two totally
separate code paths that keep track of dependencies, one can handle '!'
and one can't. The one that can't is keeping them out of Kconfig.kern.

The bit '(PCI || USB)' will be treated as 'USB'.
It will, in fact, require both PCI and USB. Also not really weird.

No, that's not what happens. It will be totally ignored. If you don't
beleive me, and you should, I know perl pretty well, you can check for
yourself. Add this line to the config VIDEDEV in
linux/drivers/media/Kconfig:
depends on (SPARC32 || MADEUPCNFIG)

VIDEDEV will still be turned on, even though both depenencies will fail.
Neither will be in Kconfig.kern either. It's not some unknown bug, I know
exactly what is wrong with the code. I was hoping that it could be fixed
before it was comitted.

Em Qua, 2006-06-21 18:52 -0700, Trent Piepho escreveu:
Wed, 21 Jun 2006, Mauro Carvalho Chehab wrote:
You beat me too it. In fact some of the changes I've been making to the build
system have been aimed at this. There is still a bug with the config-compat.h
file that I was going to fix.
I'm doing some fixes also at Makefile for it to work with 3.81, and I
should post today. This will affect config-compat.h handler, since the
kernel building system auto-generates several makefiles (like, for
example, .flexcop-dma.o.cmd), doing some conflicts with config-compat.h
rule.

The config-compat.h problem is still there. Unless you have more fixes for
this that aren't in Hg, I can fix this one.
I did this fix on another test branch (just merging config-compat.h
with .myconfig target), but I forgot to move this piece to the master.
You can fix it if you want.

It looks like there is no way to get the old behavior? I think it is
important that there is still a way to build all modules, even if the current
kernel doesn't have ISA support or whatever. It makes it much harder for
developers to do proper testing without this.
If you don't have all dependencies, building will just fail. Most claims

I can build the radio drivers, even though I have ISA turned off in my
kernel and they all need ISA. I could build and even use cx88-alsa, but
now it's turned off since I build the alsa driver devel tree out of
kernel, and have alsa turned off in the kernel.
Currently, you have an option for this: using:
make release DIR=/usr/src/linux-xxx

This will force makefile to build against another kernel version, that
may have different compiling options. This is very useful for
backporting tests, for example.

I think, there should options to do both:

A. Make all modules my kernel, as configured, can use
B. Make all modules that my kernel can build

B is what was done before, now you can o0Dnly get A. I think you will
find that drivers with extra dependencies on the kernel that most people
don't need will not get tested nearly so much.
It would be nice if we can select the behaviors. Maybe we can add a
"make allbroken" option that will force the building system to go to
(B).
I have submitted many
fixes for drivers that I don't use. I suppose it would be better, if I
never did that?
course your contributions were for good.

like it would be much easier to read the kernel's .config file. Since
autoconf.h is generated from .config, it's safe to require that .config be
there, isn't it? Can you even build v4l-dvb if it's not there? I know that
you will get non-fatal errors if $(KDIR)/.config is missing.
Seems safer to trust at the headers, especially for those users that
don't have kernel sources on their machines. It is not hard to read
the .h files, and it also provides an additional info about tri-state
dependencies.

Is there a reason you don't just read autoconf.h, which doesn't have any
recursive includes to worry about? It has all the config options in it.
The structure of config.h is somewhat more complex, for example the you
will read in asm/kgdb.h because config.h includes it.
We may use autoconf.h, but when this were introduced? using config.h
will take some more milisseconds, but it seems to be safer, in terms of
backportability.

BTW, your config.h parser can't handle tabs. You'd be better served if you
used \S, non-whitespace character, in the regular expressions instead of
[^ ]. Also useful is \w, alphanumeric plus "_". There are options in the
kernel that use lowercase letters, which your code can't handle either.
, please send me a patch for it.

It looks like this can't handle all depend lines in v4l-dvb, for example:
depends on VIDEV4L2 && !SPARC32 && !SPARC64
depends on VIDEDEV!=n
depends on RADIZLTRIX=y
depends on DVB_CRE && (PCI || USB) && I2C

The '!' dependencies will be ignored (*).
See bellow.

They don't work correctly. Look at the Kconfig.kern file, where is
SPARC32 and SPARC64? They don't appear in it at all. They should be
there, either on or off depending on the kernel. You have two totally
separate code paths that keep track of dependencies, one can handle '!'
and one can't. The one that can't is keeping them out of Kconfig.kern.
argh! anyway, we need to properly handle the expressions. Can you also
propose a patch for this?

The bit '(PCI || USB)' will be treated as 'USB'.
It will, in fact, require both PCI and USB. Also not really weird.

No, that's not what happens. It will be totally ignored. If you don't
beleive me, and you should, I know perl pretty well, you can check for
yourself. Add this line to the config VIDEDEV in
linux/drivers/media/Kconfig:
depends on (SPARC32 || MADEUPCNFIG)

VIDEDEV will still be turned on, even though both depenencies will fail.
Neither will be in Kconfig.kern either. It's not some unknown bug, I know
exactly what is wrong with the code. I was hoping that it could be fixed
before it was comitted.
We had several complains with the building system, and, even with those
fixes, now it is better to normal user than before. Please send me the
proper fixes and I'll be happy to include it.

Cheers,
Mauro.

Thu, 22 Jun 2006, Mauro Carvalho Chehab wrote:
Em Qua, 2006-06-21 18:52 -0700, Trent Piepho escreveu:
The config-compat.h problem is still there. Unless you have more fixes for
this that aren't in Hg, I can fix this one.
I did this fix on another test branch (just merging config-compat.h
with .myconfig target), but I forgot to move this piece to the master.
You can fix it if you want.

It is the script that makes config-compat.h that has the problem; the kernel's
settings aren't overridden for options that are off.

Is there a reason you don't just read autoconf.h, which doesn't have any
recursive includes to worry about? It has all the config options in it.
The structure of config.h is somewhat more complex, for example the you
will read in asm/kgdb.h because config.h includes it.
We may use autoconf.h, but when this were introduced? using config.h
will take some more milisseconds, but it seems to be safer, in terms of
backportability.

The autoconf.h file is in kernel 2.2.16 at least, in the same place and
appears to be the same format. I didn't find it with kernel 2.0.36.
Somewhere in the 2.2 series should be plenty of back-compatability.

The thing I don't like about config.h, is that it is human written and
includes that kernel debugger header file. These are not config format files
and so could have anything in them. How can you be sure the file is parsed
correctly, when it could have anything in it?