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
Hi,
On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <[email protected]> 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
Michal Piotrowski <[email protected]> writes:
> menuconfig is _part_ of kernel configuration system.
Sure, dialog is "part" of menuconfig. Your point being?
--
Krzysztof Halasa
On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <[email protected]> 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 <[email protected]>
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
On Sun, 18 Sep 2005 02:46:35 +0200 Jesper Juhl wrote:
> On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <[email protected]> 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
On 9/18/05, Randy.Dunlap <[email protected]> wrote:
> On Sun, 18 Sep 2005 02:46:35 +0200 Jesper Juhl wrote:
>
> > On 17 Sep 2005 19:16:33 +0200, Krzysztof Halasa <[email protected]> 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 <[email protected]>
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
Jesper Juhl <[email protected]> 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
On 18 Sep 2005 03:05:32 +0200, Krzysztof Halasa <[email protected]> wrote:
> Jesper Juhl <[email protected]> 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 <[email protected]>
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
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
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
> 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.
Jesper Juhl <[email protected]> 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
"Martin Fouts" <[email protected]> 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
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.
On Sun, 18 Sep 2005, Jesper Juhl wrote:
> On 18 Sep 2005 03:05:32 +0200, Krzysztof Halasa <[email protected]> wrote:
> > Jesper Juhl <[email protected]> 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*
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
Matthias Andree <[email protected]> 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