Hi all,
I noticed I had a module option being built that wasn't in menuconfig.
It is missing description. I also added a brief help message.
Signed off by: Nick Warne <[email protected]>
Nick
--
Free Software Foundation Associate Member 5508
I think there is a need for Kconfig to specify that a functionality could
be built as a module or not built at all.
Some drivers require that firmware is loaded when the driver is
initialized. The kernel has functionalities for this by using a userspace
program. However, this userspace program is only usable from modules and
not during boot while any initrd or any other file system has not yet been
mounted and yet less any processes started.
For example, Slackware 12 has a huge kernel with a lot of drivers for
different file systems and scsi cards built in. This kernel is supposed to
be a non optimized kernel that works on almost any machine even without an
initrd. In that kernel CONFIG_SCSI_QLA_FC is set to y but still it is not
possible to boot from any of those cards as the driver requires a firmware
file. Even together with an initrd image containing the firmware file it
is still not possible to use the driver as the driver require the firmware
file before any processes has been started from the initrd image.
For such drivers requiring firmware files, or if there is any other reason
that the driver doesn't work when built into the kernel it would be useful
with another choice than bool or tristate.
Best regards Henrik
--
NOTE: Dear Outlook users: Please remove me from your address books.
Read this article and you know why:
http://newsforge.com/article.pl?sid=03/08/21/143258
On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote:
> I think there is a need for Kconfig to specify that a functionality could
> be built as a module or not built at all.
I assume
depends on MODULES
should do the trick.
Sam
On Sat, 20 Oct 2007 21:17:00 +0200 Sam Ravnborg wrote:
> On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote:
> > I think there is a need for Kconfig to specify that a functionality could
> > be built as a module or not built at all.
>
> I assume
> depends on MODULES
>
> should do the trick.
Some modules use (e.g.)
depends on PCMCIA and m
but using MODULES does make more sense to me.
---
~Randy
On Sat, 20 Oct 2007 21:17:00 +0200, Sam Ravnborg said:
> On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote:
> > I think there is a need for Kconfig to specify that a functionality could
> > be built as a module or not built at all.
>
> I assume
> depends on MODULES
>
> should do the trick.
Umm... I think that will work backwards, and give you CONFIG_FOO=y
if.f the kernel *supports* modules. What he needs is to be able to say
CONFIG_FOO=n or CONFIG_FOO=m, but *ban* CONFIG_FOO=y.
(At least, in my kernel, I have MODULES=y, and several other things
from init/Kconfig have 'depends on MODULES' and also end up 'y':
% zgrep MODULE /proc/config.gz
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_MODULE_VERIFY_ELF=y
On Sun, 21 Oct 2007 00:47:38 -0400
[email protected] wrote:
> On Sat, 20 Oct 2007 21:17:00 +0200, Sam Ravnborg said:
> > I assume
> > depends on MODULES
> >
> > should do the trick.
>
> Umm... I think that will work backwards, and give you CONFIG_FOO=y
> if.f the kernel *supports* modules. What he needs is to be able to say
> CONFIG_FOO=n or CONFIG_FOO=m, but *ban* CONFIG_FOO=y.
Yes, thats right, MODULES does not ban y as would be needed. As an example
I tried to do a quick test, I edited drivers/scsi/qla2xxx/Kconfig to look
like this:
-8<-------------------------------------------------------
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
depends on PCI && SCSI && MODULES
select SCSI_FC_ATTRS
select FW_LOADER
---help---
This qla2xxx driver supports all QLogic Fibre Channel
PCI and PCIe host adapters.
By default, firmware for the ISP parts will be loaded
via the Firmware Loader interface.
ISP Firmware Filename
---------- -----------------
21xx ql2100_fw.bin
22xx ql2200_fw.bin
2300, 2312, 6312 ql2300_fw.bin
2322, 6322 ql2322_fw.bin
24xx ql2400_fw.bin
Upon request, the driver caches the firmware image until
the driver is unloaded.
Firmware images can be retrieved from:
ftp://ftp.qlogic.com/outgoing/linux/firmware/
-8<-------------------------------------------------------
The only thing that I did change was that I added "&& MODULES" to the
depends line. However, this only causes the driver to be possible to build
when you build a kernel with module support. Still tristate allows you to
build it both as a module and as a driver built into the kernel. However,
when built into the kernel the driver is unusable as it needs its firmware
which it can't reach.
Is there any other way to specify that a functionality can only be built
as a module, not built into the kernel?
In my firsta attempts to post about these tests my post ended up not on
the mailing list but as a reply to Sam Ravnborg only, apologies for
that...
Best regards Henrik
On Sun, 21 Oct 2007 12:24:02 +0200 Henrik Carlqvist wrote:
> On Sun, 21 Oct 2007 00:47:38 -0400
> [email protected] wrote:
>
> > On Sat, 20 Oct 2007 21:17:00 +0200, Sam Ravnborg said:
> > > I assume
> > > depends on MODULES
> > >
> > > should do the trick.
> >
> > Umm... I think that will work backwards, and give you CONFIG_FOO=y
> > if.f the kernel *supports* modules. What he needs is to be able to say
> > CONFIG_FOO=n or CONFIG_FOO=m, but *ban* CONFIG_FOO=y.
>
> Yes, thats right, MODULES does not ban y as would be needed. As an example
Agreed.
> I tried to do a quick test, I edited drivers/scsi/qla2xxx/Kconfig to look
> like this:
>
> -8<-------------------------------------------------------
> config SCSI_QLA_FC
> tristate "QLogic QLA2XXX Fibre Channel Support"
> depends on PCI && SCSI && MODULES
> select SCSI_FC_ATTRS
> select FW_LOADER
> ---help---
> This qla2xxx driver supports all QLogic Fibre Channel
> PCI and PCIe host adapters.
>
> By default, firmware for the ISP parts will be loaded
> via the Firmware Loader interface.
>
> ISP Firmware Filename
> ---------- -----------------
> 21xx ql2100_fw.bin
> 22xx ql2200_fw.bin
> 2300, 2312, 6312 ql2300_fw.bin
> 2322, 6322 ql2322_fw.bin
> 24xx ql2400_fw.bin
>
> Upon request, the driver caches the firmware image until
> the driver is unloaded.
>
> Firmware images can be retrieved from:
>
> ftp://ftp.qlogic.com/outgoing/linux/firmware/
> -8<-------------------------------------------------------
>
> The only thing that I did change was that I added "&& MODULES" to the
> depends line. However, this only causes the driver to be possible to build
> when you build a kernel with module support. Still tristate allows you to
> build it both as a module and as a driver built into the kernel. However,
> when built into the kernel the driver is unusable as it needs its firmware
> which it can't reach.
>
> Is there any other way to specify that a functionality can only be built
> as a module, not built into the kernel?
config FOO
depends on BAR && m
restricts FOO to module-only.
> In my firsta attempts to post about these tests my post ended up not on
> the mailing list but as a reply to Sam Ravnborg only, apologies for
> that...
---
~Randy
> config FOO
> depends on BAR && m
>
> restricts FOO to module-only.
Thanks alot! That really did the trick! With the following file:
-8<-------------------------------
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support"
depends on PCI && SCSI && m
select SCSI_FC_ATTRS
select FW_LOADER
---help---
This qla2xxx driver supports all QLogic Fibre Channel
PCI and PCIe host adapters.
By default, firmware for the ISP parts will be loaded
via the Firmware Loader interface.
ISP Firmware Filename
---------- -----------------
21xx ql2100_fw.bin
22xx ql2200_fw.bin
2300, 2312, 6312 ql2300_fw.bin
2322, 6322 ql2322_fw.bin
24xx ql2400_fw.bin
Upon request, the driver caches the firmware image until
the driver is unloaded.
Firmware images can be retrieved from:
ftp://ftp.qlogic.com/outgoing/linux/firmware/
-8<-------------------------------
It is now only possible to compile the driver as a module.
Best regards Henrik
--
NOTE: Dear Outlook users: Please remove me from your address books.
Read this article and you know why:
http://newsforge.com/article.pl?sid=03/08/21/143258
On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote:
> > Is there any other way to specify that a functionality can only be built
> > as a module, not built into the kernel?
>
> config FOO
> depends on BAR && m
>
> restricts FOO to module-only.
>
> > In my firsta attempts to post about these tests my post ended up not on
> > the mailing list but as a reply to Sam Ravnborg only, apologies for
> > that...
This is obviously the right solution.
Randy - we should document this somewhere together with more kconfig tips'n'tricks.
A new document or do we extend kconfig-language?
Sam
On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
> On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote:
> > > Is there any other way to specify that a functionality can only be built
> > > as a module, not built into the kernel?
> >
> > config FOO
> > depends on BAR && m
> >
> > restricts FOO to module-only.
> >
> > > In my firsta attempts to post about these tests my post ended up not on
> > > the mailing list but as a reply to Sam Ravnborg only, apologies for
> > > that...
>
> This is obviously the right solution.
> Randy - we should document this somewhere together with more kconfig tips'n'tricks.
Agreed.
> A new document or do we extend kconfig-language?
I don't see a need for a separate document. I would just extend
kconfig-language.
---
~Randy
On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote:
> On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
>
> > On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote:
> > > > Is there any other way to specify that a functionality can only be built
> > > > as a module, not built into the kernel?
> > >
> > > config FOO
> > > depends on BAR && m
> > >
> > > restricts FOO to module-only.
> > >
> > > > In my firsta attempts to post about these tests my post ended up not on
> > > > the mailing list but as a reply to Sam Ravnborg only, apologies for
> > > > that...
> >
> > This is obviously the right solution.
> > Randy - we should document this somewhere together with more kconfig tips'n'tricks.
>
> Agreed.
So that's one tip or trick... or common idiom.
> > A new document or do we extend kconfig-language?
>
> I don't see a need for a separate document. I would just extend
> kconfig-language.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another common idiom that we see (and sometimes have problems
with) is this:
When B (module or subsystem) uses interfaces from A (module or
subsystem), A can be linked statically into the kernel image or
can be built as loadable module(s). This limits how B can be
built. If A is linked statically into the kernel image, B can be
built statically or as loadable module(s). However, if A is built
as loadable module(s), then B must be restricted to loadable
module(s) also. This can be expressed in kconfig language as:
config B
depends on A = y || A = B
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's also a third issue: symbols that are specific to a
particular $arch, but they are in Kconfig files that are common
to all arches, so kconfig complains about symbol A refers to
unknown symbol B. (and I'm just writing this from memory, not
from testing it, so it could be off a bit.) One example of this
was PS3_PS3AV, as copied from an lkml email of 2007-feb-14:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol
'FB_PS3' refer to undefined symbol 'PS3_PS3AV'
Someone fixed this one by introducing an intermediate config symbol.
I didn't follow the details of that fix, but we see this problem
enough to warrant explaining how to handle it. E.g., recently
(from 2007-oct-14) on lkml:
$ make oldconfig >/dev/null
drivers/macintosh/Kconfig:121:warning: 'select' used by config
symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION'
Adrian, do you know of other items that should be listed here?
Thanks,
---
~Randy
On Sun, 21 Oct 2007 20:14:16 -0700 Randy Dunlap wrote:
> On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote:
>
> > On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
> >
> > > On Sun, Oct 21, 2007 at 09:45:17AM -0700, Randy Dunlap wrote:
> > > > > Is there any other way to specify that a functionality can only be built
> > > > > as a module, not built into the kernel?
> > > >
> > > > config FOO
> > > > depends on BAR && m
> > > >
> > > > restricts FOO to module-only.
> > > >
> > > > > In my firsta attempts to post about these tests my post ended up not on
> > > > > the mailing list but as a reply to Sam Ravnborg only, apologies for
> > > > > that...
> > >
> > > This is obviously the right solution.
> > > Randy - we should document this somewhere together with more kconfig tips'n'tricks.
> >
> > Agreed.
>
> So that's one tip or trick... or common idiom.
>
> > > A new document or do we extend kconfig-language?
> >
> > I don't see a need for a separate document. I would just extend
> > kconfig-language.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Another common idiom that we see (and sometimes have problems
> with) is this:
>
> When B (module or subsystem) uses interfaces from A (module or
> subsystem), A can be linked statically into the kernel image or
> can be built as loadable module(s). This limits how B can be
> built. If A is linked statically into the kernel image, B can be
> built statically or as loadable module(s). However, if A is built
> as loadable module(s), then B must be restricted to loadable
> module(s) also. This can be expressed in kconfig language as:
>
> config B
> depends on A = y || A = B
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> There's also a third issue: symbols that are specific to a
> particular $arch, but they are in Kconfig files that are common
> to all arches, so kconfig complains about symbol A refers to
> unknown symbol B. (and I'm just writing this from memory, not
> from testing it, so it could be off a bit.) One example of this
> was PS3_PS3AV, as copied from an lkml email of 2007-feb-14:
>
> drivers/video/Kconfig:1604:warning: 'select' used by config symbol
> 'FB_PS3' refer to undefined symbol 'PS3_PS3AV'
>
> Someone fixed this one by introducing an intermediate config symbol.
> I didn't follow the details of that fix, but we see this problem
> enough to warrant explaining how to handle it. E.g., recently
> (from 2007-oct-14) on lkml:
>
> $ make oldconfig >/dev/null
> drivers/macintosh/Kconfig:121:warning: 'select' used by config
> symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION'
>
>
>
> Adrian, do you know of other items that should be listed here?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Continuing with real-life kconfig fun, here's a fourth item that
people need to be aware of.
The construct:
if ARCH_OMAP
source "drivers/video/omap/Kconfig"
endif
does not prevent kconfig from reading drivers/video/omap/Kconfig.
Instead, it make all config symbols in that file be dependent upon
the ARCH_OMAP symbol. Adding a config symbol dependency like this
is a common problem that causes config menus not to be displayed as
they should be (not indented or not subordinate as expected).
---
~Randy
On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote:
> I think there is a need for Kconfig to specify that a functionality could
> be built as a module or not built at all.
>
> Some drivers require that firmware is loaded when the driver is
> initialized. The kernel has functionalities for this by using a userspace
> program. However, this userspace program is only usable from modules and
> not during boot while any initrd or any other file system has not yet been
> mounted and yet less any processes started.
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't
be allowed to be built in.
Christoph Hellwig wrote:
> On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote:
>> I think there is a need for Kconfig to specify that a functionality could
>> be built as a module or not built at all.
>>
>> Some drivers require that firmware is loaded when the driver is
>> initialized. The kernel has functionalities for this by using a userspace
>> program. However, this userspace program is only usable from modules and
>> not during boot while any initrd or any other file system has not yet been
>> mounted and yet less any processes started.
>
> That's wrong. You can load firmware from the initramfs even if the
> driver is built in. There is no valid reason why a driver shouldn't
> be allowed to be built in.
Could you please explain how this is supposed to work?
As far as I understand, the kernel initializes all built-in drivers, and
only then starts /init in initramfs (which is then supposed to start
udevd and load firmware) - but that's too late.
--
Alexander E. Patrakov
On Mon, Oct 22, 2007 at 04:32:19PM +0600, Alexander E. Patrakov wrote:
> >That's wrong. You can load firmware from the initramfs even if the
> >driver is built in. There is no valid reason why a driver shouldn't
> >be allowed to be built in.
>
> Could you please explain how this is supposed to work?
>
> As far as I understand, the kernel initializes all built-in drivers, and
> only then starts /init in initramfs (which is then supposed to start
> udevd and load firmware) - but that's too late.
populate_rootfs is a rootfs_initcall which happens before all the driver
initcalls.
Christoph Hellwig wrote:
> On Mon, Oct 22, 2007 at 04:32:19PM +0600, Alexander E. Patrakov wrote:
>
>>> That's wrong. You can load firmware from the initramfs even if the
>>> driver is built in. There is no valid reason why a driver shouldn't
>>> be allowed to be built in.
>>>
>> Could you please explain how this is supposed to work?
>>
>> As far as I understand, the kernel initializes all built-in drivers, and
>> only then starts /init in initramfs (which is then supposed to start
>> udevd and load firmware) - but that's too late.
>>
>
> populate_rootfs is a rootfs_initcall which happens before all the driver
> initcalls.
>
Correct, but irrelevant. The firmware indeed gets unpacked to rootfs
before all driver initcalls, but stays as a dead weight during them,
because udev (started by /init, which happens in init_post() called by
kernel_init() after all initcalls) is needed to load this firmware.
Yes, there is a call to usermodehelper_init() before the initcalls in
do_basic_setup(), this does mean that firmware can be loaded by means of
the old and obsolete /sbin/hotplug mechanism, but who has /sbin/hotplug now?
--
Alexander E. Patrakov
Henrik Carlqvist wrote:
> I think there is a need for Kconfig to specify that a functionality could
> be built as a module or not built at all.
>
> Some drivers require that firmware is loaded when the driver is
> initialized. The kernel has functionalities for this by using a userspace
> program. However, this userspace program is only usable from modules and
> not during boot while any initrd or any other file system has not yet been
> mounted and yet less any processes started.
>
I cannot see a reason to outlaw built-in driver
for this case. The device needing a firmware file
is not an argument for making the driver modular only.
The idea for the fix is simple enough. Such a driver should
not initialize just because the kernel itself boots up. It should
wait until the firmware is provided. (which surely can be
done from an initrd, so you can use that device as
the root fs if need be.)
Similar example: Drivers for all sorts of USB thingies
can be built into the kernel. Still, these drivers don't
initialize until hardware is plugged in. Which could happen
weeks later. They just wait until a device is ready for use.
Surely other drivers can do the same - wait until
the device is ready (firmware gets loaded) and
start to use the device at that point.
> For example, Slackware 12 has a huge kernel with a lot of drivers for
> different file systems and scsi cards built in. This kernel is supposed to
> be a non optimized kernel that works on almost any machine even without an
> initrd. In that kernel CONFIG_SCSI_QLA_FC is set to y but still it is not
> possible to boot from any of those cards as the driver requires a firmware
> file.
Then an initrd-less boot is impossible for this
device - even the modular approach needs
an initrd to load the module if you want that
device as root fs.
> Even together with an initrd image containing the firmware file it
> is still not possible to use the driver as the driver require the firmware
> file before any processes has been started from the initrd image.
>
So fix that! If the driver can wait for its firmware
in the modular case, then it can wait for its firmware
in the built-in case too. That capability may require some
coding of course, but _depending_ on modularity is
silly. There are enough people out there that simply
don't want modules, and even leave out module support
when compiling. There should be no need for modules
when you compile the kernel specifically for
the machine.
> For such drivers requiring firmware files, or if there is any other reason
> that the driver doesn't work when built into the kernel it would be useful
> with another choice than bool or tristate.
>
Better to just fix the driver - which can't be that
hard for anyone capable of making the driver in
the first place. Modularity and firmware loading
are not connected. One is for kernel flexibility, the other
is for making a particular device work.
Helge Hafting
On Mon, Oct 22, 2007 at 05:27:51PM +0600, Alexander E. Patrakov wrote:
> Yes, there is a call to usermodehelper_init() before the initcalls in
> do_basic_setup(), this does mean that firmware can be loaded by means of
> the old and obsolete /sbin/hotplug mechanism, but who has /sbin/hotplug now?
I do. We're not going to cripple the kernel just because you use fucked
up userspace.
Christoph Hellwig wrote:
> On Mon, Oct 22, 2007 at 05:27:51PM +0600, Alexander E. Patrakov wrote:
>
>> Yes, there is a call to usermodehelper_init() before the initcalls in
>> do_basic_setup(), this does mean that firmware can be loaded by means of
>> the old and obsolete /sbin/hotplug mechanism, but who has /sbin/hotplug now?
>>
>
> I do. We're not going to cripple the kernel just because you use <censored> userspace.
>
>
AFAIK, there were good reasons (effect similar to fork bomb on a system
with large number of, e.g., SCSI disks - Greg KH obviously knows more
details) to drop /sbin/hotplug from all distributions in favour of udev.
Anyway, the "hotplug" package is no longer supported by its author. So
there is no option to use a non-<censored> from your viewpoint but still
supported-upstream userspace.
As already mentioned in a different subthread, the solution is to wait
for the firmware in the background, so that the built-in case also
starts working. Drivers that don't do this (e.g. qla2xxx) must be fixed,
but for now, IMHO, it does make sense to mark them as non-working in the
non-modular case.
--
Alexander E. Patrakov
On Mon, 22 Oct 2007 13:46:43 +0200
> > In that kernel CONFIG_SCSI_QLA_FC is set to y but still it is not
> > possible to boot from any of those cards as the driver requires a
> > firmware file.
> Then an initrd-less boot is impossible for this
> device - even the modular approach needs
> an initrd to load the module if you want that
> device as root fs.
Today I was able to boot from an FC disk with a modified kernel 2.6.21
without any initrd. The modification was basically to replace the contents
of drivers/scsi/qla2xxx with the code in qla2xxx-v8.02.02-dist.tgz from
ftp://ftp.qlogic.com/outgoing/linux/beta/8.x/ as that driver has the
firmware built in.
> Better to just fix the driver - which can't be that
> hard for anyone capable of making the driver in
> the first place. Modularity and firmware loading
> are not connected. One is for kernel flexibility, the other
> is for making a particular device work.
In this case I finally did prefer a solution which didn't depend on any
separate firmware file. Being able to boot straight to the FC drive
without the need of initrd was really nice.
When I first asked my question I assumed that I would have to compile the
driver as a module and use an initrd containing both the module and the
firmware together with userspace mechanisms to load the firmware. This
solution with a replaced qla2xxx driver was not the answer to my first
question about bool and tristate, but that question also got answered in
this thread.
Best regards Henrik
Am I the only one seeing this issue?
On Saturday 20 October 2007 12:57:55 Nick Warne wrote:
> Hi all,
>
> I noticed I had a module option being built that wasn't in menuconfig.
>
> It is missing description. I also added a brief help message.
>
> Signed off by: Nick Warne <[email protected]>
Not using this patch, using menuconfig the scsi_wait option doesn't appear
anywhere for me to be able to it turn off - yet grep'ing .config will always
show this option as being built as a module.
Nick
--
Free Software Foundation Associate Member 5508
Hi,
On Monday 22 October 2007, Randy Dunlap wrote:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Another common idiom that we see (and sometimes have problems
> with) is this:
>
> When B (module or subsystem) uses interfaces from A (module or
> subsystem), A can be linked statically into the kernel image or
> can be built as loadable module(s). This limits how B can be
> built. If A is linked statically into the kernel image, B can be
> built statically or as loadable module(s). However, if A is built
> as loadable module(s), then B must be restricted to loadable
> module(s) also. This can be expressed in kconfig language as:
>
> config B
> depends on A = y || A = B
What you describe is a simple "depends on A" and your example won't work
because it adds a recursive dependency.
bye, Roman