init-kconfig - easy way to embrace Linux's kconfig
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
This may also be useful if folks want to test R&D code on a smaller compartamentalized codebase.
If you find this useful and you'd like to help keep it in sync, send patches my way as the kernel's kconfig evolves. The code is up on gitlab [3].
Do we want to document this option on Linux in case folks want to try and embrace kconfig on their own for other projects?
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
[3] https://gitlab.com/mcgrof/init-kconfig
Luis
Quoted 11 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
Quoted 8 lines
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
Is there a *fundamental* reason that we couldn't have this *be* Linux kconfig, whether pulled in by submodule or regular merges, and avoid having any divergence at all?
Quoted 21 lines · Josh Triplett
Quoted 11 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
Quoted 8 lines
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
Quoted 3 lines
Is there a *fundamental* reason that we couldn't have this *be* Linux kconfig, whether pulled in by submodule or regular merges, and avoid having any divergence at all?
The structure of kconfig in Linux would have to be changed to make adoption and sync easier. If that is a goal we wish to embrace, I'm all for it.
Luis
Quoted 22 lines · Luis Chamberlain
Quoted 21 lines · Josh Triplett
Quoted 19 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
Quoted 7 lines
Quoted 3 lines
Is there a *fundamental* reason that we couldn't have this *be* Linux kconfig, whether pulled in by submodule or regular merges, and avoid having any divergence at all?
The structure of kconfig in Linux would have to be changed to make adoption and sync easier. If that is a goal we wish to embrace, I'm all for it.
I would *love* to see Kconfig in Linux evolved to be more easily reused.
Quoted 1 line · Josh Triplett
I would *love* to see
Kconfigin Linux evolved to be more easily reused.
This *can* happen. Let me itemize a few things off of my head I think would need to be done as its at least fresh in my head now:
All we need from scripts/Kbuild.include is filechk and kecho (what I have in my scripts/Kbuild.include). This could be moved to scripts/Kbuild.basic, and so would make sync'ing easier.
The scripts/kconfig/Makefile would need a respective modifications to make it work independently, see my scripts/kconfig/Makefile. Perhaps the biggest pain was resolving the target for scripts/kconfig/.mconf-cfg. If somehow we end up with a file which could work for both environments we're set.
Other than this we'd need a simple script, say scripts/copy-kconfig.sh which would copy over only those files I took from scripts/kconfig.
There's a few things to consider for a split copy / demo:
* versioning *is not* part of kconfig
* object building *is not* part of kconfig
But the problem I faced was that to demo kconfig I had to use *something* for versioning and object building. The object building is simple, and the versioning scheme was just copied from Linux.
What I ended up with the smallest demo I could come up with.
Luis
Quoted 21 lines · On Thu, 4 Oct 2018 13:53:19 -0700 Luis Chamberlain <[email protected]> wrote:
Quoted 1 line · Josh Triplett
I would *love* to see
Kconfigin Linux evolved to be more easily reused.This *can* happen. Let me itemize a few things off of my head I think would need to be done as its at least fresh in my head now:
All we need from
scripts/Kbuild.includeis filechk and kecho (what I have in myscripts/Kbuild.include). This could be moved toscripts/Kbuild.basic, and so would make sync'ing easier.The
scripts/kconfig/Makefilewould need a respective modifications to make it work independently, see myscripts/kconfig/Makefile. Perhaps the biggest pain was resolving the target forscripts/kconfig/.mconf-cfg. If somehow we end up with a file which could work for both environments we're set.Other than this we'd need a simple script, say
scripts/copy-kconfig.shwhich would copy over only those files I took fromscripts/kconfig.There's a few things to consider for a split copy / demo:
Quoted 9 lines
* versioning *is not* part of kconfig
* object building *is not* part of kconfigBut the problem I faced was that to demo kconfig I had to use *something* for versioning and object building. The object building is simple, and the versioning scheme was just copied from Linux.
What I ended up with the smallest demo I could come up with.
Are you attending Linux Plumbers in Vancouver? Because I think this would be a very interesting BoF there.
-- Steve
Quoted 30 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
This may also be useful if folks want to test R&D code on a smaller compartamentalized codebase.
If you find this useful and you'd like to help keep it in sync, send patches my way as the kernel's kconfig evolves. The code is up on gitlab [3].
Do we want to document this option on Linux in case folks want to try and embrace kconfig on their own for other projects?
Quoted 7 lines
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
[3] https://gitlab.com/mcgrof/init-kconfigLuis
Hi Luis,
Any crossover with Ulf's recent announcement?
https://lore.kernel.org/lkml/CAFkk2KQ-sC=bAd9fCkOVPNmZn8m+EZfpZtirE+J5VpvW120sxQ@mail.gmail.com/
thanx,
Signature · 1 line
~Randy
Hi,
Quoted 12 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
Quoted 8 lines
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
Syncing kconfig files is easy
since the files are collected in the single place, scripts/kconfig/.
It is true you need some efforts to introduce Kconfig in your project, but once established, it is just a matter of copying files under scripts/kconfig.
Copying stuff directly from Linux would be as easy as doing so from your init-kconfig.
Quoted 10 lines
This may also be useful if folks want to test R&D code on a smaller compartamentalized codebase.
If you find this useful and you'd like to help keep it in sync, send patches my way as the kernel's kconfig evolves. The code is up on gitlab [3].
Do we want to document this option on Linux in case folks want to try and embrace kconfig on their own for other projects?
Quoted 6 lines
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
[3] https://gitlab.com/mcgrof/init-kconfigLuis
Looks like init-kconfig is trying to build some objects as demo.
obj-y = main.o
obj-$(CONFIG_FOO) += foo.o
obj-$(CONFIG_BAR) += bar.o
obj-$(CONFIG_BAZ) += baz.o
obj-$(CONFIG_ALPHA) += alpha/
FWIW, this is something I played with some time ago.
Kbuild Skeleton
https://github.com/masahir0y/kbuild_skeleton
It consists of some core Makefiles and Kconfig.
From the time-stamp, it is already 6 years too old.
I am not sure if it is useful for people,
if so, it is pretty easy to sync up with the latest Linux.
Signature · 2 lines
Best Regards Masahiro Yamada
Quoted 27 lines · Masahiro Yamada
Hi,
Quoted 12 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
Quoted 8 lines
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
Quoted 1 line
Syncing kconfig files is easy
I disagree. Even as someone who has done this in the past and is an experience developer it hasn't been a swift process by any mean.
Quoted 1 line
since the files are collected in the single place,
scripts/kconfig/.
That helps, but isn't enough.
Quoted 3 lines
It is true you need some efforts to introduce
Kconfigin your project, but once established, it is just a matter of copying files underscripts/kconfig.
Nope, there is other random subtle work needed, a few of things which I noted earlier before I forgot what things I had to do / change manually which we not obvious.
Quoted 2 lines
Copying stuff directly from Linux would be as easy as doing so from your init-kconfig.
Clearly I disagree, the idea with init-kconfig is the process of upkeeping is done centrally, and so users really do just take that and go.
If we want to make the process smoother upstream, then great.
Quoted 18 lines
Quoted 10 lines
This may also be useful if folks want to test R&D code on a smaller compartamentalized codebase.
If you find this useful and you'd like to help keep it in sync, send patches my way as the kernel's kconfig evolves. The code is up on gitlab [3].
Do we want to document this option on Linux in case folks want to try and embrace kconfig on their own for other projects?
Quoted 7 lines
Looks like init-kconfig is trying to build some objects as demo.
obj-y = main.o
obj-$(CONFIG_FOO) += foo.o
obj-$(CONFIG_BAR) += bar.o
obj-$(CONFIG_BAZ) += baz.o
obj-$(CONFIG_ALPHA) += alpha/
Indeed, we are spoiled with our build process. Mimicing this was actually a separate effort, and so I didn't match on par, but just enough to demo a basic use.
Quoted 5 lines
FWIW, this is something I played with some time ago.
KbuildSkeleton
https://github.com/masahir0y/kbuild_skeleton
Quoted 7 lines
It consists of some core Makefiles and
Kconfig.From the time-stamp, it is already 6 years too old.
I am not sure if it is useful for people,
if so, it is pretty easy to sync up with the latest Linux.
Groovy, indeed this is useful thanks. I still think this process can be improved to allow perhaps both kconfig and its object makefiles magic & dependency tracking thing be easily sharable. I however understand if we don't want that to be a goal, there would have to be obvious gains for it. I don't think we're there yet. Right now it would just make it easier for enhancements to trickle out to the community and/or fixes to bubble up, however I don't expect many people doing much kconfig hacking outside of Linux. Perhaps the best advantage I can think for this as a goal for us right now is to enable researchers with sandboxes, proof of concepts, so that we can eventually get the fruits of such work.
Luis
Quoted 31 lines · Luis Chamberlain
Every now and then a project is born, and they decide to use Linux's kconfig to enable configuration of their project. As it stands we *know* kconfig is now used in at least over 12 different projects [0]. I myself added kconfig to one as well years ago. Even research reveals that kconfig has become one of the leading industrial variability modeling languages [1] [2].
What is often difficult to do though is to start off using kconfig and integrating it into a project. Or updating / syncing to the latest kconfig from upstream Linux.
I had yet another need to use kconfig for another small project so decided to make a clean template others can use and help keep it in sync. This is a passive fork which aims to keep in sync with the Linux kernel's latest kconfig to make it easier to keep up to date and to enable new projects to use and embrace kconfig on their own. The goal is *not* to fork kconfig and evolve it separately, but rather keep in sync with the evolution of kconfig on Linux to make it easier for projects to use kconfig and also update their own kconfig when needed.
This may also be useful if folks want to test R&D code on a smaller compartamentalized codebase.
If you find this useful and you'd like to help keep it in sync, send patches my way as the kernel's kconfig evolves. The code is up on gitlab).) [3].
Do we want to document this option on Linux in case folks want to try and embrace kconfig on their own for other projects?
Quoted 6 lines
[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf
[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf
[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf
[3] https://gitlab.com/mcgrof/init-kconfigLuis
Shameless self-plug:
There's also a Python Kconfig implementation that's starting to get picked up by several projects: https://github.com/ulfalizer/kconfiglib
It has a terminal menuconfig interface with a lot more features than mconf (a demonstration is available at
https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/menuconfig.gif),
and can also be used e.g. to generate cross-referenced Kconfig documentation that includes propagated dependencies:
https://docs.zephyrproject.org/latest/reference/kconfig/index.html
(note: heavy page).
Kconfiglib is based around a library (an old version appears in e.g. U-Boot and Yocto, and a newer version in e.g. Espressif). The documentation generation is just a script
(https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/scripts/genrest.py),
and the same goes for the menuconfig and the other tools. The core library takes part of all the trickiness related to evaluating symbols.
I realize there would probably be massive opposition to adding a Python dependency to a core part of the kernel, so I'm not going for that. For most other projects, I think it's a good fit though.
Cheers,
Ulf