Why don't we separate menuconfig from the kernel?

Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

Hi,

A number of packages (e.g., busybox) use some, more or less broken,
version of menuconfig. Would it make sense to move menuconfig to
a separate well-defined package?

Nooo? Why not?
-- 
Krzysztof Halasa

Re: Why don't we separate menuconfig from the kernel?

[Michal Piotrowski]

Hi,

On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Hi,
> 
> A number of packages (e.g., busybox) use some, more or less broken,
> version of menuconfig. Would it make sense to move menuconfig to
> a separate well-defined package?
> 
> Nooo? Why not?
> --
> Krzysztof Halasa

menuconfig is _part_ of kernel configuration system.

Regards,
Michal Piotrowski

Re: Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

Michal Piotrowski <michal.k.k.piotrowski@gmail.com> writes:

> menuconfig is _part_ of kernel configuration system.

Sure, dialog is "part" of menuconfig. Your point being?
-- 
Krzysztof Halasa

Re: Why don't we separate menuconfig from the kernel?

[Jesper Juhl]

On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Hi,
> 
> A number of packages (e.g., busybox) use some, more or less broken,
> version of menuconfig. Would it make sense to move menuconfig to
> a separate well-defined package?
> 

What exactely is it you want to make a sepperate package?

menuconfig is just a little bit of the kbuild system which also
includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
a dialog based frontend to the kbuild system which consists of
configuration options, help texts, dependency info etc.

menuconfig uses `dialog` to present its menus and dialog boxes (using
ncurses), and if you want to build something else using dialog, then
that already exists as a sepperate program that has nothing to do with
kbuild. On my system (Slackware) it's installed as /bin/dialog and
comes from the pkgtools-10.2.0-i486-5 package.

I don't think it makes much sense to split the parts of kbuild that
make up menuconfig out into a standalone thing. kbuild (and thus
menuconfig) has little use outside the kernel.  The `dialog` tool is a
different matter, but that is already a sepperately developed thing (
http://hightek.org/dialog/ ) .


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Why don't we separate menuconfig from the kernel?

[Randy.Dunlap]

On Sun, 18 Sep 2005 02:46:35 +0200 Jesper Juhl wrote:

> On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> > Hi,
> > 
> > A number of packages (e.g., busybox) use some, more or less broken,
> > version of menuconfig. Would it make sense to move menuconfig to
> > a separate well-defined package?
> > 
> 
> What exactely is it you want to make a sepperate package?
> 
> menuconfig is just a little bit of the kbuild system which also
> includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
> a dialog based frontend to the kbuild system which consists of
> configuration options, help texts, dependency info etc.
> 
> menuconfig uses `dialog` to present its menus and dialog boxes (using
> ncurses), and if you want to build something else using dialog, then
> that already exists as a sepperate program that has nothing to do with
> kbuild. On my system (Slackware) it's installed as /bin/dialog and
> comes from the pkgtools-10.2.0-i486-5 package.
> 
> I don't think it makes much sense to split the parts of kbuild that
> make up menuconfig out into a standalone thing. kbuild (and thus
> menuconfig) has little use outside the kernel.  The `dialog` tool is a
> different matter, but that is already a sepperately developed thing (
> http://hightek.org/dialog/ ) .

OTOH, Christoph Hellwig used to maintain 'mconf' out-of-tree
and it worked decently, so it seems not a big deal to so do.

---
~Randy
You can't do anything without having to do something else first.
-- Belefant's Law

Re: Why don't we separate menuconfig from the kernel?

[Jesper Juhl]

On 9/18/05, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> On Sun, 18 Sep 2005 02:46:35 +0200 Jesper Juhl wrote:
> 
> > On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> > > Hi,
> > >
> > > A number of packages (e.g., busybox) use some, more or less broken,
> > > version of menuconfig. Would it make sense to move menuconfig to
> > > a separate well-defined package?
> > >
> >
> > What exactely is it you want to make a sepperate package?
> >
> > menuconfig is just a little bit of the kbuild system which also
> > includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
> > a dialog based frontend to the kbuild system which consists of
> > configuration options, help texts, dependency info etc.
> >
> > menuconfig uses `dialog` to present its menus and dialog boxes (using
> > ncurses), and if you want to build something else using dialog, then
> > that already exists as a sepperate program that has nothing to do with
> > kbuild. On my system (Slackware) it's installed as /bin/dialog and
> > comes from the pkgtools-10.2.0-i486-5 package.
> >
> > I don't think it makes much sense to split the parts of kbuild that
> > make up menuconfig out into a standalone thing. kbuild (and thus
> > menuconfig) has little use outside the kernel.  The `dialog` tool is a
> > different matter, but that is already a sepperately developed thing (
> > http://hightek.org/dialog/ ) .
> 
> OTOH, Christoph Hellwig used to maintain 'mconf' out-of-tree
> and it worked decently, so it seems not a big deal to so do.
> 
I still fail to see the point of doing so, even if doable.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

Jesper Juhl <jesper.juhl@gmail.com> writes:

> What exactely is it you want to make a sepperate package?

Just the menuconfig (mconf) at first. OTOH it might make sense to
move them all.

> menuconfig is just a little bit of the kbuild system which also
> includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
> a dialog based frontend to the kbuild system which consists of
> configuration options, help texts, dependency info etc.

Sure, that's what I mean. It's used for configuring the kernel, but
other packages use it (well, some version) too. Example: busybox.

There is no much point in keeping more than one copy. They are
completely independent of the kernel, all the kernel wants is to pass
them some Kconfig file and expect data in .config. (oldconfig uses
.config.old).

There is a question about config language and possible future changes.
Not a serious problem IMHO.

> I don't think it makes much sense to split the parts of kbuild that
> make up menuconfig out into a standalone thing. kbuild (and thus
> menuconfig) has little use outside the kernel.

It's not exactly the case.
-- 
Krzysztof Halasa

Re: Why don't we separate menuconfig from the kernel?

[Jesper Juhl]

On 18 Sep 2005 03:05:32 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Jesper Juhl <jesper.juhl@gmail.com> writes:
> 
> > What exactely is it you want to make a sepperate package?
> 
> Just the menuconfig (mconf) at first. OTOH it might make sense to
> move them all.
> 

And if you do that, then you'd be shipping a kernel source that it
would be impossible for users to configure without installing
sepperate tools - and tools (unlike for example gcc) that very few
people would have a need for outside configuring their kernel.
Not a good idea in my oppinion.


> > menuconfig is just a little bit of the kbuild system which also
> > includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
> > a dialog based frontend to the kbuild system which consists of
> > configuration options, help texts, dependency info etc.
> 
> Sure, that's what I mean. It's used for configuring the kernel, but
> other packages use it (well, some version) too. Example: busybox.
> 
> There is no much point in keeping more than one copy. They are
> completely independent of the kernel, all the kernel wants is to pass

I think there's a point; the kernel source should contain its own
configuration tools.
Just think of how many users would complain that "the kernel is
broken, I can't configure it" and similar. Also, what would ensure
that the config/build tools would always stay in sync with other
kernel changes?  Right now things stay in sync since everyone are
using the same version of the tools that ship with any given kernel
and if something breaks it's fixed up along with everything else. Move
it out of the kernel tree and you'll end up having users trying to use
old tools to build a new kernel (or new tools to build an old kernel)
and there's bound to be breakage at some point - why have those extra
problems?


> them some Kconfig file and expect data in .config. (oldconfig uses
> .config.old).
> 
if you extract a fresh kernel source and copy your old .config to
.config in the new kernel source dir, then "make oldconfig" will read
that .config and write a new one as well...

> There is a question about config language and possible future changes.
> Not a serious problem IMHO.
> 
I disagree.


> > I don't think it makes much sense to split the parts of kbuild that
> > make up menuconfig out into a standalone thing. kbuild (and thus
> > menuconfig) has little use outside the kernel.
> 
> It's not exactly the case.

If someone wants to use the tools outside the kernel, then let them
fork off a version and maintain that out-of tree. The in-kernel and
out-of-kernel could borrow code and fixes from eachother if
needed/wanted, but I personally believe there needs to be a version
shipping as part of the source tree.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

Jesper Juhl <jesper.juhl@gmail.com> writes:

> And if you do that, then you'd be shipping a kernel source that it
> would be impossible for users to configure without installing
> sepperate tools - and tools (unlike for example gcc) that very few
> people would have a need for outside configuring their kernel.

So what? We already have tools which are needed for just one thing.
This one is at least for configuring more than one program.

Of course, the kernel (kbuild or running the kernel) requires many
things, isn't it the UNIX philosophy?

Remember ksymoops? _That_ was a single purpose.

> I think there's a point; the kernel source should contain its own
> configuration tools.

Why only them? Why not the compiler toolchain (encoded with sharutils)
and some shell so you can bootstrap it over serial console? :-)

> Just think of how many users would complain that "the kernel is
> broken, I can't configure it" and similar.

Such users use distribution kernels. Distributions have package
dependencies which can install anything needed automatically.

How many times have you seen people complaining that the kernel is
broken as one "can't compile it" (due to missing binutils or even gcc)?

> Also, what would ensure
> that the config/build tools would always stay in sync with other
> kernel changes?

People sending patches, of course, and the maintainer doing kernel work
as well. What ensures that, say, udev stays in sync? And udev is new
and changing.

> if you extract a fresh kernel source and copy your old .config to
> .config in the new kernel source dir, then "make oldconfig" will read
> that .config and write a new one as well...

Sure, I don't know why I mentioned .config.old, they all use it the same.
Writing at 3 am, possibly.

> If someone wants to use the tools outside the kernel, then let them
> fork off a version and maintain that out-of tree. The in-kernel and
> out-of-kernel could borrow code and fixes from eachother if
> needed/wanted,

That's what is currently done, but it doesn't seem so smart from
maintenance POV. And UNIX philosophy, you know.
-- 
Krzysztof Halasa

Re: Why don't we separate menuconfig from the kernel?

[Daniel Barkalow]

On Sun, 18 Sep 2005, Jesper Juhl wrote:

> On 18 Sep 2005 03:05:32 +0200, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> > Jesper Juhl <jesper.juhl@gmail.com> writes:
> > 
> > > What exactely is it you want to make a sepperate package?
> > 
> > Just the menuconfig (mconf) at first. OTOH it might make sense to
> > move them all.
> > 
> 
> And if you do that, then you'd be shipping a kernel source that it
> would be impossible for users to configure without installing
> sepperate tools - and tools (unlike for example gcc) that very few
> people would have a need for outside configuring their kernel.
> Not a good idea in my oppinion.

There are, in my opinion, two issues: where is kconfig maintained, and is 
it shipped with the kernel. I think each kernel tarball should contain the 
version of kconfig it expects to be configured with, because there isn't a 
commitment to having kconfig be compatible between versions. On the other 
hand, I don't see any reason that it has to be maintained in the kernel's 
git repositories.

Git actually supports this. Sam could have a repository with only the 
kbuild files, and people could pull it normally, and it would all work 
trivially (so long as people didn't try to modify kbuild by sending 
patches to Linus). The only tricky thing is that this repository can't 
have the linux-with-kbuild repository as an ancestor, because then it 
would remove stuff; so, if people want kbuild history, it would need to be 
recreated separately.

The advantage would be that people who wanted the latest version of kbuild 
could always get it without the kernel; the disadvantage is that kernel 
developers who want to change kbuild would have to remember not to send 
this changes into the kernel tree. I don't know if it would be more or 
less convenient for Sam not to have the rest of the kernel tree around 
kbuild.

	-Daniel
*This .sig left intentionally blank*

Re: Why don't we separate menuconfig from the kernel?

[Matthias Andree]

On Sun, 18 Sep 2005, Krzysztof Halasa wrote:

> > menuconfig is just a little bit of the kbuild system which also
> > includes xconfig, config, gconfig, oldconfig, etc.  menuconfig is just
> > a dialog based frontend to the kbuild system which consists of
> > configuration options, help texts, dependency info etc.
> 
> Sure, that's what I mean. It's used for configuring the kernel, but
> other packages use it (well, some version) too. Example: busybox.

One of Linux's main problems is that all daemons that drive kernel core
functionality are cluttered over various separate projects. While this
allows for independent development, it's annoying if you need to hunt
down the various daemons (udev, autofs, hotplug, iproute, to name the
first that come to mind) only to find out the new version doesn't suit
your distro. I'd rather wish there was a standard kernel "daemons"
package.

> There is no much point in keeping more than one copy. They are

Why should other projects that recycle kernel code impact how the kernel
itself is made.

-- 
Matthias Andree

Re: Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

Matthias Andree <matthias.andree@gmx.de> writes:

> One of Linux's main problems is that all daemons that drive kernel core
> functionality are cluttered over various separate projects. While this
> allows for independent development, it's annoying if you need to hunt
> down the various daemons (udev, autofs, hotplug, iproute, to name the
> first that come to mind) only to find out the new version doesn't suit
> your distro. I'd rather wish there was a standard kernel "daemons"
> package.

Who would select what is a standard kernel daemon and what is not?
Who would maintain the package?

> Why should other projects that recycle kernel code impact how the kernel
> itself is made.

It's NOT kernel code.
-- 
Krzysztof Halasa

RE: Why don't we separate menuconfig from the kernel?

[Martin Fouts]

I don't have a patch yet, but I've just spent a bit of time looking at
how kbuild works, and I believe there is a fairly straightforward way to
keep kbuild in the kernel tree but make it easy to split it out so that
someone could use it as a separate tool.

If this idea, appropriately modified, makes sense, I'll spend a bit of
time to do a patch and set it up.

The basic idea is that kbuild stays in the kernel source tree, but a
simple script is used to grab a copy of it out of the tree.  That copy
is maintained as a separate "build/configuration" package, and the
maintainer (yes, I'm volunteering) would keep the two versions in (near)
sync.

After a quick glance, it looks like one would want to copy

Documentation/kbuild/*
Scripts/kconfig/*
Makefile

To this new copy.  The only real work to get started, it appears, and
the reason why I'd rather have a discussion before I start, would be to
split the toplevel Makefile up a bit, so that the 'pure kbuild' bits
were moved into an include file. It's really that include file, not the
toplevel Makefile that would need to be copied.

I suggest doing this because most of the make-related knowledge about
kbuild itself is in that Makefile, but non-kernel users would not want
the kernel specific targets.

I know of two other packages (busybox and ptxdist) that use kconfig now,
and have been contemplating it for some of my projects, as well, so I'm
interested enough to take the project on.

Marty

Re: Why don't we separate menuconfig from the kernel?

[Sam Ravnborg]

On Sat, Sep 17, 2005 at 06:53:55PM -0700, Martin Fouts wrote:
> I don't have a patch yet, but I've just spent a bit of time looking at
> how kbuild works, and I believe there is a fairly straightforward way to
> keep kbuild in the kernel tree but make it easy to split it out so that
> someone could use it as a separate tool.
> 
> If this idea, appropriately modified, makes sense, I'll spend a bit of
> time to do a patch and set it up.
> 
> The basic idea is that kbuild stays in the kernel source tree, but a
> simple script is used to grab a copy of it out of the tree.  That copy
> is maintained as a separate "build/configuration" package, and the
> maintainer (yes, I'm volunteering) would keep the two versions in (near)
> sync.
> 
> After a quick glance, it looks like one would want to copy
> 
> Documentation/kbuild/*
> Scripts/kconfig/*
> Makefile
> 
> To this new copy.  The only real work to get started, it appears, and
> the reason why I'd rather have a discussion before I start, would be to
> split the toplevel Makefile up a bit, so that the 'pure kbuild' bits
> were moved into an include file. It's really that include file, not the
> toplevel Makefile that would need to be copied.
> 
> I suggest doing this because most of the make-related knowledge about
> kbuild itself is in that Makefile, but non-kernel users would not want
> the kernel specific targets.
> 
> I know of two other packages (busybox and ptxdist) that use kconfig now,
> and have been contemplating it for some of my projects, as well, so I'm
> interested enough to take the project on.
I'm a bit confused.
Do you want to take a copy of kbuild or kconfig?

kbuild is much more intiminate than kconfig althougth the latter has a
few kernel only issues too.

	Sam

Re: Why don't we separate menuconfig from the kernel?

[Krzysztof Halasa]

"Martin Fouts" <Martin.Fouts@palmsource.com> writes:

> I don't have a patch yet, but I've just spent a bit of time looking at
> how kbuild works, and I believe there is a fairly straightforward way to
> keep kbuild in the kernel tree but make it easy to split it out so that
> someone could use it as a separate tool.

That is obvious and people already are doing that, what I'm thinking of is
moving menuconfig or *config out of the kernel so there is one well-defined
external package.
-- 
Krzysztof Halasa

Re: Why don't we separate menuconfig from the kernel?

[Ian Campbell]

On Sun, 2005-09-18 at 12:36 +0200, Krzysztof Halasa wrote:
> What I'm thinking of is moving menuconfig or *config out of the
> kernel so there is one well-defined external package.

If you really think it is worthwhile you could start maintaining a
package containing a copy of *config from the most recent kernel for all
these other projects to use, that would reduce the number of copies to
just 2, it would be a good start...

Ian.

-- 
Ian Campbell

Void where prohibited by law.

RE: Why don't we separate menuconfig from the kernel?

[Martin Fouts]

 
> I'm a bit confused.
> Do you want to take a copy of kbuild or kconfig?
> 
> kbuild is much more intiminate than kconfig althougth the 
> latter has a few kernel only issues too.

Kconfig is nice without kbuild, but if you want to automate it in a
makefile, you'll want the bits of kbuild from the top level makefile
that do that.

So I guess my personal answer is I want kconfig with just enough kbuild
to make it nice.