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
On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> 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.
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?
On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > 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.
>
> 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
On Thu, Oct 04, 2018 at 01:39:50PM -0700, Luis Chamberlain wrote:
> On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> > On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > > 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.
> >
> > 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.
On Thu, Oct 04, 2018 at 01:41:18PM -0700, Josh Triplett wrote:
> I would *love* to see Kconfig in 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
On Thu, 4 Oct 2018 13:53:19 -0700
Luis Chamberlain <[email protected]> wrote:
> On Thu, Oct 04, 2018 at 01:41:18PM -0700, Josh Triplett wrote:
> > I would *love* to see Kconfig in 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.
>
Are you attending Linux Plumbers in Vancouver? Because I think this
would be a very interesting BoF there.
-- Steve
On 10/4/18 1:02 PM, Luis Chamberlain wrote:
> 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
>
Hi Luis,
Any crossover with Ulf's recent announcement?
https://lore.kernel.org/lkml/CAFkk2KQ-sC=bAd9fCkOVPNmZn8m+EZfpZtirE+J5VpvW120sxQ@mail.gmail.com/
thanx,
--
~Randy
Hi,
On Fri, Oct 5, 2018 at 5:03 AM Luis Chamberlain <[email protected]> wrote:
>
> 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.
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.
> 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
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.
--
Best Regards
Masahiro Yamada
On Thu, Oct 4, 2018 at 10:03 PM Luis Chamberlain <[email protected]> wrote:
>
> 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
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
On Fri, Oct 05, 2018 at 07:48:34PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
>
> On Fri, Oct 5, 2018 at 5:03 AM Luis Chamberlain <[email protected]> wrote:
> >
> > 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.
>
>
> 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.
> since the files are collected in the single place, scripts/kconfig/.
That helps, but isn't enough.
> 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.
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.
> 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.
> > 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
>
>
> 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.
> 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.
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
){kind=link}