Hi,
No code available yet, but while doing the compras I've physically crashed
(on my bike) into an idea:
localconfig(9) Generating local configuration localconfig(9)
NAME
localconfig - generate a .config for the local computer
SYNOPSIS
make localconfig
make dep ... etc... pp...
DESCRIPTION
Generate a .config for the local computer, so that the kernel
could be built right in that moment. Therefor the local computer
is being examined, probed and configured and all the devices that
we find go into your .config.
The version is probably never 100% accurate, it might be a good
idea to manually recheck the .config (e.g. via make menuconfig)
This is supposed to be a first step into a new direction where
we no longer copy vendor kernels from the vendor CD to the system
in the first position, but rather configure a new kernel for each
system, hoping that somewhen the boxes will be fast enough to
handle it in no time.
AVAILABILITY
Linux 2.7+
SEE ALSO
make(1), kbuild(9)
scripts/localconfig.pl
AUTHORS
(...)
Thunder from the hill <[email protected]>
BUGS
Well, how could I tell yet?!
Linux build system $EPOCH+$x localconfig(9)
Now I want your comments...
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Sat, Aug 24, 2002 at 08:12:46AM -0600, Thunder from the hill wrote:
> Hi,
>
> No code available yet, but while doing the compras I've physically crashed
> (on my bike) into an idea:
>
>
>
> localconfig(9) Generating local configuration localconfig(9)
>
> NAME
> localconfig - generate a .config for the local computer
Yow! The return of Aunt Tillie compiling a kernel! :-)
--
/"\ |
\ / ASCII RIBBON CAMPAIGN | "Who is this General Failure, and
X AGAINST HTML MAIL | what is he doing on my harddisk?"
/ \
Hi,
On Sat, 24 Aug 2002, Toon van der Pas wrote:
> > localconfig(9) Generating local configuration localconfig(9)
>
> Yow! The return of Aunt Tillie compiling a kernel! :-)
Oh, please. This was not my intention. I was just suggesting something
like this could be done in the real world, also don't I have these ideas.
I just think it might save you some time when you've accidently rm'd your
.config, and all you want to have is a .config for the local box. Also
wouldn't I load all the modules one by one, possibly.
If you think it's a _deadly_bad_idea_to_do_ please tell me. It is, after
all, just an RFC, means I request you to comment on this. I could even ask
for kernel protection for the mice.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Sat, Aug 24, 2002 at 03:25:58PM -0600, Thunder from the hill wrote:
> If you think it's a _deadly_bad_idea_to_do_ please tell me. It is, after
> all, just an RFC, means I request you to comment on this. I could even ask
> for kernel protection for the mice.
It's an old idea that has been implemented at least once... I suggest
you read the archives
john
--
"When your name is Winner, that's it. You don't need a nickname."
- Loser Lane
Hi,
On Sat, 24 Aug 2002, Thunder from the hill wrote:
> This is supposed to be a first step into a new direction where
> we no longer copy vendor kernels from the vendor CD to the system
> in the first position, but rather configure a new kernel for each
> system, hoping that somewhen the boxes will be fast enough to
> handle it in no time.
Let me be clear on this. I'm not for an "Aunt T*ll*e compiling a kernel",
but I'm rather thinking about following the comments on non-binary
distribution of programs. (Remember the talks when somebody suggested that
programs might be distributed more flexible if they're configured and
compiled on install?)
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Sat, 24 Aug 2002 08:12:46 -0600 (MDT)
Thunder from the hill <[email protected]> wrote:
> Generate a .config for the local computer, so that the kernel
> could be built right in that moment. Therefor the local computer
> is being examined, probed and configured and all the devices
> that we find go into your .config.
It turns out that the autoconfigure script included in CML2 is actually
an adaptation of kautoconfigure (Giacomo Catenazzi <[email protected]>,
http://sf.net/projects/kautoconfigure), just tweaked to use CML2 and
python... a slightly older version that uses sh (well, bash) is still
available. The ruleset is something like 8 months old by now, but the
features provided are really pretty nifty. I used it once and it worked
very nicely. I don't know if it was the, erm, downfall of CML2 that
killed this project, but I wouldn't mind seeing it come back.
8/24/2002 11:12:46 PM, Thunder from the hill <[email protected]> wrote:
> Generate a .config for the local computer, so that the kernel
> could be built right in that moment. Therefor the local computer
> is being examined, probed and configured and all the devices that
> we find go into your .config.
>
> The version is probably never 100% accurate, it might be a good
> idea to manually recheck the .config (e.g. via make menuconfig)
>
> This is supposed to be a first step into a new direction where
> we no longer copy vendor kernels from the vendor CD to the system
> in the first position, but rather configure a new kernel for each
> system, hoping that somewhen the boxes will be fast enough to
> handle it in no time.
I disagree. It can't make things better or faster if you have to recheck the
.config file manually. When you are going through the checking part you
could just easily set the options too.
People compiling kernel know their machine and they also know what and
where must be set in the menuconfig. By the way there are a lot of machine
independent things that can't be discovered using a script, like network
options, preemption, filesystems etc. So users would have to set these
things at least and at this point I can't see how it could save time for me.
Nobody knows better than me what my computer has or what I want to see
compiled in the kernel. I think it would make things less reliable and instead
of saving time it would add extra check/time and work.
On the other hand it would be a great first step towards to have a full or almost
full automated kernel compilation for those who don't know enough or anything
about their computers or they don't have the necessary skills. Sooner or later
there will be a demand for it. Just think about avarage programmers. They now
just set up their M$ thing and start writing programs without the knowladge of
computers or deeper level of operating systems. They see only source codes of
THEIR programs and therefore they run into trouble if a hardware/driver problem
arises. (Of course I disagree with this kind of behavior) It could be useful for
this case, not for saving time.
And these people are not the ones without any computer skills. They have just
chosen another field in computer science.
Gabor
Hi,
I think this version is supposed to illustrate much better what I've had
in my mind.
localconfig(9) Generating local configuration localconfig(9)
NAME
localconfig - generate a .config for the local computer
SYNOPSIS
make localconfig
make dep ... etc... pp...
DESCRIPTION
Generate a .config for the local computer, so that the kernel
could be built right in that moment. Therefor the local
computer is being examined, probed and configured and all the
devices that we find go into your .config.
This is supposed to be a first step into a new direction where
we no longer copy vendor packages from the vendor CD to the
system in the first place, but rather compile new packages for
each system, hoping that somewhen the boxes will be fast
enough to handle it in no time. It's basically a binary
distribution -> source distribution transition.
AVAILABILITY
Linux 2.7+
SEE ALSO
make(1), kbuild(9)
scripts/localconfig.pl
AUTHORS
(...)
Thunder from the hill <[email protected]>
BUGS
The version is probably never overly accurate, it might be a
good idea to manually recheck the .config (e.g. via make
menuconfig) in the first versions.
Linux build system Aug 25, 2002 localconfig(9)
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
> This is supposed to be a first step into a new direction where
> we no longer copy vendor packages from the vendor CD to the
> system in the first place, but rather compile new packages for
> each system, hoping that somewhen the boxes will be fast
> enough to handle it in no time. It's basically a binary
> distribution -> source distribution transition.
You might also like to take a look at Gentoo Linux, which I hear does
precisely this, except with all the packages the user chooses to install.
(Hopefully I've not malformed the name of the distro too much.)
T.
On Sat, 24 Aug 2002, Thunder from the hill wrote:
> Oh, please. This was not my intention. I was just suggesting something
> like this could be done in the real world, also don't I have these ideas.
> I just think it might save you some time when you've accidently rm'd your
> .config, and all you want to have is a .config for the local box. Also
> wouldn't I load all the modules one by one, possibly.
>
> If you think it's a _deadly_bad_idea_to_do_ please tell me. It is, after
> all, just an RFC, means I request you to comment on this. I could even ask
> for kernel protection for the mice.
For this kind of thing, code talks. Otherwise no one will take heed.
Zwane
--
function.linuxpower.ca
> > I just think it might save you some time when you've accidently rm'd your
> > .config, and all you want to have is a .config for the local box. Also
> > wouldn't I load all the modules one by one, possibly.
> For this kind of thing, code talks. Otherwise no one will take heed.
Even with code noone seems to have taken heed. The code has been
available for ages. I think it's very useful. gunzip </proc/config.gz
gives you the config of the running kernel, make cloneconfig sets up
the source tree. Free and convenient with every SuSE kernel.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.orcon.net.nz/ Please do not CC list postings to me.
Hi,
On Sun, 25 Aug 2002, Zwane Mwaikambo wrote:
> For this kind of thing, code talks. Otherwise no one will take heed.
I can't currently supply code, but the thing I'm doing is:
- parse the dmesg for the vital stuff (the things that were loaded up to
the moment may be used very often...)
- Find out what code it's belonging to
- Configure that code in
- The rest is CONFIG_MODULE
So what?
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
Hi,
On Sun, 25 Aug 2002, Volker Kuhlmann wrote:
> Even with code noone seems to have taken heed. The code has been
> available for ages. I think it's very useful.
I think you're talking about different code.
> gunzip </proc/config.gz gives you the config of the running kernel,
What if the current kernel is some allmodconfig, and you don't want that,
for some reason? And by the way, that's not related to the transition I
mentioned. If you want that, just go and do make allmodconfig.
> make cloneconfig
Why not make oldconfig?
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Sat, Aug 24, 2002 at 03:25:58PM -0600, Thunder from the hill wrote:
> Hi,
>
> On Sat, 24 Aug 2002, Toon van der Pas wrote:
> > > localconfig(9) Generating local configuration localconfig(9)
> >
> > Yow! The return of Aunt Tillie compiling a kernel! :-)
>
> Oh, please. This was not my intention.
My apologies. I really couldn't resist..
> If you think it's a _deadly_bad_idea_to_do_ please tell me. It is,
> after all, just an RFC, means I request you to comment on this.
> I could even ask for kernel protection for the mice.
A serious question about your proposal then:
The .config file doesn't excusively contain information regarding
what hardware to support. It also carries a lot of information about
the functionality and the optimzations the user wishes to incorporate
in his kernel. How would localconfig deal with that?
Regards,
Toon.
BTW: Considering that you are not out of your mind (most of the
time), I admire your courage in bringing up this subject. ;-)
--
/"\ |
\ / ASCII RIBBON CAMPAIGN | "Who is this General Failure, and
X AGAINST HTML MAIL | what is he doing on my harddisk?"
/ \
Hi,
On Sun, 25 Aug 2002, Toon van der Pas wrote:
> > If you think it's a _deadly_bad_idea_to_do_ please tell me. It is,
> > after all, just an RFC, means I request you to comment on this.
> > I could even ask for kernel protection for the mice.
>
> A serious question about your proposal then:
> The .config file doesn't excusively contain information regarding
> what hardware to support. It also carries a lot of information about
> the functionality and the optimzations the user wishes to incorporate
> in his kernel. How would localconfig deal with that?
Well, the idea is to
- scan the kernel messages for things that got loaded
- figure the hardware configuration
- figure out guessable optimizations
- use the default values for the rest
I don't want to decide between "y" and "n". That would go wrong. The only
thing is that there *should* be a decision on whether the support is vital
for boot or not, if not we compile as module.
This statement is not valid for debug options, though...
> BTW: Considering that you are not out of your mind (most of the
> time), I admire your courage in bringing up this subject. ;-)
I wonder whether that's a good thing...
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
On Sun, Aug 25, 2002 at 05:17:24AM -0600, Thunder from the hill wrote:
> Hi,
>
> On Sun, 25 Aug 2002, Volker Kuhlmann wrote:
> > Even with code noone seems to have taken heed. The code has been
> > available for ages. I think it's very useful.
>
> I think you're talking about different code.
>
> > gunzip </proc/config.gz gives you the config of the running kernel,
>
> What if the current kernel is some allmodconfig, and you don't want that,
> for some reason? And by the way, that's not related to the transition I
> mentioned. If you want that, just go and do make allmodconfig.
>
> > make cloneconfig
>
> Why not make oldconfig?
Because then you'd just be comparing the current to the default config, not
much gained there...
Hi.
I have some bash code (to probe hardware), an hardware/driver database
and a python script to partly generate the database direct from
kernel sources.
It should be in http://people.debian.org/~cate/files/kautoconfigure
and in http://people.debian.org/~cate/files/gnome-os
If someone find it usefull I can continue to work on that.
ciao
cate
Thunder from the hill wrote:
> Hi,
>
> On Sun, 25 Aug 2002, Zwane Mwaikambo wrote:
>
>>For this kind of thing, code talks. Otherwise no one will take heed.
>
>
> I can't currently supply code, but the thing I'm doing is:
>
> - parse the dmesg for the vital stuff (the things that were loaded up to
> the moment may be used very often...)
> - Find out what code it's belonging to
> - Configure that code in
> - The rest is CONFIG_MODULE
>
> So what?
>
> Thunder