Re: Automatic .config generation

Re: Automatic .config generation

[jmerkey]

Scott Robert Ladd wrote:

Now that's a great idea ..... :-) 

Jeff

>Is there a utility that creates a .config based on analysis of the
>target system?
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Automatic .config generation

[Scott Robert Ladd]

Is there a utility that creates a .config based on analysis of the
target system?

Re: Automatic .config generation

[Matthias-Christian Ott]

jmerkey wrote:
> Scott Robert Ladd wrote:
> 
> Now that's a great idea ..... :-)
> Jeff
> 
>> Is there a utility that creates a .config based on analysis of the
>> target system?
>> -
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>  
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
I think Netbsd has something like this, maybe this is a good example.

Matthias-Christian Ott

Re: Automatic .config generation

[Lennart Sorensen]

On Thu, May 12, 2005 at 11:07:24AM -0600, jmerkey wrote:
> Scott Robert Ladd wrote:
> >Is there a utility that creates a .config based on analysis of the
> >target system?
> 
> Now that's a great idea ..... :-) 

And how would it guess if you want iptables support enabled or not?
Which device drivers to include is not the only thing that goes in
.config after all.

A simpler solution is turn on everything as modules, and let
hotplug/discover figure it out at boot time. :)

Len Sorensen

Re: Automatic .config generation

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Thu, 2005-05-12 at 20:21 +0200, Matthias-Christian Ott wrote:
> jmerkey wrote:
> > Scott Robert Ladd wrote:
> > 
> > Now that's a great idea ..... :-)
> > Jeff
> > 
> >> Is there a utility that creates a .config based on analysis of the
> >> target system?
> >> -

This probably isn't what you are looking for, but I posted this a while
back, and have found this useful for myself.  

I wrote a simple perl script (attached) to turn off all the modules that
are not being used on the current system. Obviously if you have a USB
device that's not attached, it would get turned off too. But this was
nice to see what modules I actually needed to get a system running.

You first compile the kernel with the default distribution .config.
Then run this script in the directory of the kernel that's running, and
has that .config available. The output of a .config with all non
necessary modules turned off is sent to standard output.

-- Steve


[-- Attachment #2: streamline_config.pl --]
[-- Type: application/x-perl, Size: 2851 bytes --]

Re: Automatic .config generation

[Edgar Toernig]

jmerkey wrote:
>
> Scott Robert Ladd wrote:
> >
> >Is there a utility that creates a .config based on analysis of the
> >target system?
>
> Now that's a great idea ..... :-)

Not really new though :-)

    http://sourceforge.net/projects/kautoconfigure/

Ciao, ET.

Re: Automatic .config generation

[Borislav Petkov]

On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> jmerkey wrote:
> > Scott Robert Ladd wrote:
> > >Is there a utility that creates a .config based on analysis of the
> > >target system?
> >
> > Now that's a great idea ..... :-)
>
> Not really new though :-)
>
>     http://sourceforge.net/projects/kautoconfigure/
>
> Ciao, ET.

how about /proc/config.gz.. although this was pretty recent IIRC.

Regards,
Boris.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Automatic .config generation

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Sun, 15 May 2005 09:03:42 +0200, Borislav Petkov said:
> On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> > jmerkey wrote:
> > > Scott Robert Ladd wrote:
> > > >Is there a utility that creates a .config based on analysis of the
> > > >target system?

> how about /proc/config.gz.. although this was pretty recent IIRC.

That describes the currently running kernel *as built* - so for instance
booting a RedHat kernel on almost anything will show 3 zillion things
built as modules - including 2.5 zillion things that aren't needed in the
current config (for instance, every single sound card driver may be included).

What is desired is a utility that will do an lspci/lsusb/etc and build up
a .config that matches *the current hardware* (for instance, only including
a module for the one sound card that's actually installed).

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Automatic .config generation

[Jesper Juhl]

On Sun, 15 May 2005 Valdis.Kletnieks@vt.edu wrote:

> On Sun, 15 May 2005 09:03:42 +0200, Borislav Petkov said:
> > On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> > > jmerkey wrote:
> > > > Scott Robert Ladd wrote:
> > > > >Is there a utility that creates a .config based on analysis of
> the
> > > > >target system?
> > how about /proc/config.gz.. although this was pretty recent IIRC.
> That describes the currently running kernel *as built* - so for instance
> booting a RedHat kernel on almost anything will show 3 zillion things
> built as modules - including 2.5 zillion things that aren't needed in
> the
> current config (for instance, every single sound card driver may be
> included).
> What is desired is a utility that will do an lspci/lsusb/etc and build
> up
> a .config that matches *the current hardware* (for instance, only
> including
> a module for the one sound card that's actually installed).
> 
What's the big gain? Where's the harm in just building all the sound 
modules - you only load one in the end anyway, and the space taken by the 
other modules is negligible with the disk sizes of today I'd say (ok, 
there's some extra build time involved, but that shouldn't be a big deal 
either). Or just use good old "make menuconfig" to only enable the module 
you want. Besides, it's not as if you have to redo your kernel config from 
scratch every time you want a new kernel. Make your favorite config once, 
build and install that kernel and then when you want a newer kernel simply 
either cd linux-<version>; zcat /proc/config.gz > .config ; make oldconfig 
and then build the new kernel using your previous config.

-- 
Jesper Juhl

Re: Automatic .config generation

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

On Sun, 15 May 2005 11:52:51 +0200, Jesper Juhl said:
> What's the big gain? Where's the harm in just building all the sound
> modules - you only load one in the end anyway, and the space taken by the
> other modules is negligible with the disk sizes of today I'd say (ok,
> there's some extra build time involved, but that shouldn't be a big deal

If you're doing building and testing on an older/slower box, the build
time and disk size matters - there's 481 'y' or 'm' in my current .config, versus
1701 in the Fedora -1287 kernel.  Being able to do 3 build/reboot loops in
an hour versus one every 90 mins makes a big difference.  Being able to do a
build in 400M instead of 2G means that a 7G /usr/src/ partition can hold 8 or 9
trees, rather than 3 (useful for those "when did this start" regressions, especially
in combo with that 20 min versus 90 build time. ;)

> you want. Besides, it's not as if you have to redo your kernel config from
> scratch every time you want a new kernel. Make your favorite config once, 
> build and install that kernel and then when you want a newer kernel simply 
> either cd linux-<version>; zcat /proc/config.gz > .config ; make oldconfig 
> and then build the new kernel using your previous config.

Yes, that's easy if you're working on *the same hardware*, so new device drivers
aren't of interest, and the only thing 'make oldconfig' will prompt you for is
new non-driver functionality. However, that's not everybody...

The function is for building streamlined configs for new systems - you get
in a Frobozz2005 laptop, and although you probably have your own favorite set
of values for things like which netfilter modules to build, you probably have
*no* idea right off what device drivers you need. So you end up either going
the RedHat route and building it *all* anyhow, or spending a lot of time
figuring out which drivers you need for *this* box.  And you can't even trust
the vendor sometimes - the Dell laptop I'm typing on was part of a larger order.
A co-worker got another C840, and we had both ordered the same CD/RW-DVD drive.
Machines had consecutive Dell service/serial numbers - and different vendor
drives (mine had a Toshiba, his had something else).

I won't even *start* on the number of subtly different AC'97-ish sound chips
Dell has gone through.. ;)

If you have a better solution to the "minimize *total* time to build optimized
kernels for 12 different machines that just got dropped on your workbench
this morning" feel free to share.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Automatic .config generation

[aq]

On 5/13/05, Edgar Toernig <froese@gmx.de> wrote:
> jmerkey wrote:
> >
> > Scott Robert Ladd wrote:
> > >
> > >Is there a utility that creates a .config based on analysis of the
> > >target system?
> >
> > Now that's a great idea ..... :-)
> 
> Not really new though :-)
> 
>    http://sourceforge.net/projects/kautoconfigure/
> 

is this project basically dead?

this idea is not new, but still top of my wish-list for kernel
compiling. just wonder when such a great tool come up?

regards,
aq

Re: Automatic .config generation

[Scott Robert Ladd]

Jesper Juhl wrote:
> Where's the harm in just building all the sound 
> modules - you only load one in the end anyway, and the space taken by the 
> other modules is negligible with the disk sizes of today I'd say (ok, 
> there's some extra build time involved, but that shouldn't be a big deal 
> either).

A desktop computer with a large hard drive may be the norm for kernel
developers, but it isn't (by far) the only environment where the kernel
is built. Embedded devices, small systems, older hardware, and
heterogenous networks all require a bit more finesse than a simple
"build it all and throw the mess at the hardware" approach.

The complexity of the kernel is growing, making it more difficult for
people to understand what they need and how to get it. It seems to me
that a computer can analyze itself to determine the "best" build
options. That's part of the reasoning behind my Acovea technology --
reducing complexity through smarter software.

    http://www.coyotegulch.com/products/acovea

Acovea isn't directly applicable to the kernel, but the idea of the
computer performing self-discovery is certainly valid. Once I get
another project finished, I'm going to take a more formal look at kernel
configuration, and see what might be done.

..Scott

Re: Automatic .config generation

[Steven Rostedt]

Once again, check out
http://www.kihontech.com/code/streamline_config.pl :-)


On Sun, 2005-05-15 at 07:13 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 15 May 2005 11:52:51 +0200, Jesper Juhl said:
> > What's the big gain? Where's the harm in just building all the sound
> > modules - you only load one in the end anyway, and the space taken by the
> > other modules is negligible with the disk sizes of today I'd say (ok,
> > there's some extra build time involved, but that shouldn't be a big deal
> 
> If you're doing building and testing on an older/slower box, the build
> time and disk size matters - there's 481 'y' or 'm' in my current .config, versus
> 1701 in the Fedora -1287 kernel.  Being able to do 3 build/reboot loops in
> an hour versus one every 90 mins makes a big difference.  Being able to do a
> build in 400M instead of 2G means that a 7G /usr/src/ partition can hold 8 or 9
> trees, rather than 3 (useful for those "when did this start" regressions, especially
> in combo with that 20 min versus 90 build time. ;)
> 

I have to do a bit of traveling, and one time I didn't want to bring my
main laptop, and instead brought along my 75MHz IBM Thinkpad 755CX. (a
professor laughed at me and jokingly offered me his palm pilot as an
upgrade!).  I actually used this to do kernel compiles. So this can take
quite some time on this type of hardware.

> > you want. Besides, it's not as if you have to redo your kernel config from
> > scratch every time you want a new kernel. Make your favorite config once, 
> > build and install that kernel and then when you want a newer kernel simply 
> > either cd linux-<version>; zcat /proc/config.gz > .config ; make oldconfig 
> > and then build the new kernel using your previous config.
> 
> Yes, that's easy if you're working on *the same hardware*, so new device drivers
> aren't of interest, and the only thing 'make oldconfig' will prompt you for is
> new non-driver functionality. However, that's not everybody...
> 
> The function is for building streamlined configs for new systems - you get
> in a Frobozz2005 laptop, and although you probably have your own favorite set
> of values for things like which netfilter modules to build, you probably have
> *no* idea right off what device drivers you need. So you end up either going
> the RedHat route and building it *all* anyhow, or spending a lot of time
> figuring out which drivers you need for *this* box.  And you can't even trust
> the vendor sometimes - the Dell laptop I'm typing on was part of a larger order.
> A co-worker got another C840, and we had both ordered the same CD/RW-DVD drive.
> Machines had consecutive Dell service/serial numbers - and different vendor
> drives (mine had a Toshiba, his had something else).
> 

With this simple script, you only need to use what the distribution
installed (hopefully it also installs the .config that is used). And the
script will remove all the modules but the ones that are loaded.

-- Steve

Re: Automatic .config generation

[Ahmad Reza Cheraghi]

--- Alex Riesen <raa.lkml@gmail.com> wrote:

> On 9/8/05, Ahmad Reza Cheraghi
> <a_r_cheraghi@yahoo.com> wrote:
> > I made this Framework to generate a .config based
> on a
> > Target-System. Right-now it works on my Laptop
> Acer
> 
> how about teaching it to generate .config using just
> sysfs and lsbus?

Thats another way, to find the Hardware(better than
dmesg). But is this always installed on a nacked
Kernel? And i think, lsbus is not supported by the new
sysfsutils. 
The best thing is for detecting the Hardware is
directly from the I/O, and the only program I know is
lspci.
 
> So noone will need to contact you regarding adding
> their system to
> your files, especially when all the information is
> already present in
> the kernel in a very parsable form (pci.ids, for
> example).
Thangs, didn't know that!
 
> The whole scenary will then shorten to:
> $ make autoconfig
> $ make
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: Automatic .config generation

[Alex Riesen]

On 9/8/05, Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com> wrote:
> I made this Framework to generate a .config based on a
> Target-System. Right-now it works on my Laptop Acer

how about teaching it to generate .config using just sysfs and lsbus?
So noone will need to contact you regarding adding their system to
your files, especially when all the information is already present in
the kernel in a very parsable form (pci.ids, for example).

The whole scenary will then shorten to:
$ make autoconfig
$ make

Automatic .config generation

[Ahmad Reza Cheraghi]

Hi

I made this Framework to generate a .config based on a
Target-System. Right-now it works on my Laptop Acer
TM290. It has to be upgradet to other system as well.
But it's realy easy just read the readme. I would be
realy happy if some of you guys give me some comments
and suggestion about it.

readme:
http://www.energyparty.de/ahmad/readme

A patch for the Kernel:
http://www.energyparty.de/ahmad/autoconfig_0_1_patch.tgz

sources:
http://www.energyparty.de/ahmad/autoconfig_0_1.tgz


Regard

Ahmad Reza Cheraghi


	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: Automatic .config generation

[Ahmad Reza Cheraghi]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

(update)

Hi everybody

For my endthesis I wrote a Framework that
automatically generates a Kernel-Configuration .
A Kernel-Patch, the sources and a readme are attached
to this mail. For more details please read the readme.

Comments and suggestion are welcome.

Regards
Ahmad Reze Cheraghi



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[-- Attachment #2: 1469308934-autoconfig_0_1_patch.tgz --]
[-- Type: application/x-gtar, Size: 14904 bytes --]

[-- Attachment #3: 2327105889-autoconfig_0_1.tgz --]
[-- Type: application/x-gtar, Size: 17752 bytes --]

[-- Attachment #4: 2655387580-readme --]
[-- Type: application/octet-stream, Size: 6789 bytes --]


For my EndThesis, in the Niederrhein University of Applied Sciences,
I've right-now almost finished a framework that generates a
.config file based on the target system. This program should help people to
generate a linux kernel Config without spending a lot of time at the
configuration.

The basic idea of the framework is, that the options asked by "make config"
will be redirected to a set of scripts. Those scripts answers are depending on the
hardware/system the option-question.

This framework is now in its test stage. It works on my Acer Laptop(TM
291LMI with Pentium M and Radeon 9700). That means,
- the framework is functional
- but additional scripts have to be written for other type of
  hardware/functionality (far away from completed)
- an additional Help is an output that the autoconfig gives out after his work is done, which tells
  us that in some menus the amount of needed options did not elected.

Constist:
********

The Linux Auto-Config consist of Files, auto_conf.c, an upgraded conf.c and Makefile, a directory
(rules) which contains a rules_list and the scripts, and a xmlparser written by Tim Hockin.



install:
*******

You've just to download the autoconfig*.tgz and unpack it in the /usr/src/<KERNELVERSION>/scripts/kconfig
directory. 
To run it go to your the <KERNELVERSION> directory and type

for using the sources:

(root) # cd /tmp/
(root) # tar xvfz autoconfig*.tgz
(root) # cp -r autoconfig*/* /usr/src/<KERNELVERSION>/scripts/kconfig
(root) # cd /usr/src/<KERNELVERSION>/
(root) # make autoconfig

for using the patch:

(root) # cd /tmp/
(root) # tar xvfz autoconfig*-patch.tgz
(root) # cd /usr/src/<KERNELVERSION>/
(root) #root) # patch -p1 < /tmp/autoconfig*/sources.patch
(root) # chmod u+x scripts/kconfig/rules/*
(root) # make autoconfig

!! Be carefull: since we want to build a config from scratch on, the .config will be deleted automaticly.


How does it work:
*****************

The trick of all is a framworking program, that means adding binaries or scripts without 
touching the real program. The program starts like if you are starting a  make config, but at that point 
where it wants an input from you, the function auto_conf gets called with that option-question
as a parameter. We are comparing this option with in a list manual-written
Kconfig option. Each of those options in the list has its own script which will be 
executed in parallel by accordance. For putting an option in the rules_list you need
the Option and a script that does the work for the option and then gives a value
to the stout. This value will be redirected through a pipe to our main program which will
write the config-name for the option into the .config file. 




How to add a rule:
*******************


The basic of the script is that it must give an answer to stdout. 
Since the rules_list is written in xml there are some conditions for adding rules.
To add a rule (for the specified option), you have to know first the option name
and the name of the menu that contains it. 
The easiest way, to do this, is to run make menuconfig, and see in which menu or submenu your option belongs to. 
Each of those has its own XML-Tag:


<rules>: beginnging of the list.

<menu name="menu name" must_have=" number ">:
	    Has the attribute "name" and "must_have". In attribute "name" the name of the menu should be written.
	    Attribute "must_have" shows the min. number of option, that in a menu should be choosen for a proper Kernel. 
	    <menu> can contains options or submenus(the same as <menu>). 

<option name="option name"> rule </option>
 	    In the attribut name the option name should be written. And the contain of the Option Tag 
	    is the name of rule that belongs to that option.

example:

<rules>
      <menu name="Networking support" must_have="1">
         <option name="Networking support">egrep1.pm "Network|Ethernet"</option>
         <menu name="Networking menus">
            <option name="Packet socket">yes1.pm</option>
            <option name="Packet socket: mmapped IO">yes1.pm</option>
	</menu>
      </menu>
</rules>


How to make a rule
*******************

A rule can be either a script or binary or... The main job is to 
give out an answer to stout for the actually option-question, it doesn't matter
how.
 
We have three types of answer:

sym-answers:     either y, n, m or \n.

string-answer:   can be maximal 128 characters

option-answer: 	 By the manual configuration normally you have to type an number
		 but a rule for an option should give out an y, if it want to be choosen. 
		




For example:    the option is "Networking Support"
		the program looks in the our list (which is called rules_list)
		to find the "Networking Support" and if this option is in there,
		a certain script (which we call it a rule)  will be executed. 
		In this example the script name is hw_grep1.pm which 
		reads a given Parameter and searches for this Parameter,
		lspci and dmesg with the help of grep. In this Case the Parameter 
		will be "Ethernet|Network".
		
		hw_grep1.pm:

		$found='';
		$found=`lspci | grep "@ARGV"`;
		if($found ne '') {
        		print("y\n");
		}
		else {
        		$found=`grep -E "@ARGV" /var/log/dmesg `;
        		if($found ne ''){
                		print("y\n");
        		}
        		else {
		                print("n\n");
        		}
		}
		1;

		
			    

		
		This script checks if there is an Ethernet or 
		a Network card  on the target System.
		If it is true, it gives  in this case a 'y' to stdout. 
		And for some options there can't be any script-rules, for instance software such as FTP or TCPIP etc...,
		those question either get answered as 'build in' or as 'module'.
		!! the answers must always have a '\n' at the end

The rule-binary should be copied in the directory <KERNELVERSION>/scripts/kconfig/rules/



Messages:
*******************

When the amount of needed Options in some menus are not choosen,
messages will be given out in the stdout, at the end of the configuration.
Containig Name of the menus.

This can be happen:

1. if for some options they rules are not applied. The reason for that is for some Hardware Option there is no rule.

2. if your System doesn't support the Hardware i.e. you don't have an ethernet Card.

In this case either your upgrade the autoconfig with rules or your contact me. 

If you are getting messages please include the following information:

1. a copy of your lspci, /proc/cpuinfo and /var/log/dmesg

2. a copy of your messages



TO DO:
*******************

1. The Framework has to be extend for the Systems that aren't supported.

2 .A way to ask for the Hardware-Devices directly from the I/O.
 

Contact:
*******************

Suggestion and comments are welcome. 

Email: Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com>

Re: Automatic .config generation

[Ahmad Reza Cheraghi]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi

For my endthesis I wrote a Framework that
automatically generates a Kernel-Configuration .
A Kernel-Patch, the sources and a readme are attached
to this mail. For more details please read the readme.

Comments and suggestion are welcome.

Regards
Ahmad Reze Cheraghi


	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

[-- Attachment #2: 2327105889-autoconfig_0_1.tgz --]
[-- Type: application/x-gtar, Size: 17742 bytes --]

[-- Attachment #3: 2655387580-readme --]
[-- Type: application/octet-stream, Size: 6762 bytes --]


For my EndThesis, in the Niederrhein University of Applied Sciences,
I've right-now almost finished a framework that generates a
.config file based on the target system. This program should help people to
generate a linux kernel Config without spending a lot of time at the
configuration.

The basic idea of the framework is, that the options asked by "make config"
will be redirected to a set of scripts. Those scripts answers are depending on the
hardware/system the option-question.

This framework is now in its test stage. It works on my Acer Laptop(TM
291LMI with Pentium M and Radeon 9700). That means,
- the framework is functional
- but additional scripts have to be written for other type of
  hardware/functionality (far away from completed)
- an additional Help is an output that the autoconfig gives out after his work is done, which tells
  us that in some menus the amount of needed options did not elected.

Constist:
********

The Linux Auto-Config consist of Files, auto_conf.c, an upgraded conf.c and Makefile, a directory
(rules) which contains a rules_list and the scripts, and a xmlparser written by Tim Hockin.



install:
*******

You've just to download the autoconfig*.tgz and unpack it in the /usr/src/<KERNELVERSION>/scripts/kconfig
directory. 
To run it go to your the <KERNELVERSION> directory and type

for using the sources:

(root) # cd /tmp/
(root) # tar xvfz autoconfig*.tgz
(root) # cp -r autoconfig*/* /usr/src/<KERNELVERSION>/scripts/kconfig
(root) # cd /usr/src/<KERNELVERSION>/

for using the patch:

(root) # cd /tmp/
(root) # tar xvfz autoconfig*-patch.tgz
(root) # cd /usr/src/<KERNELVERSION>/
(root) #root) # patch -p1 < /tmp/autoconfig*/sources.patch
(root) # chmod u+x scripts/kconfig/rules/*
(root) # make auconfig

!! Be carefull: since we want to build a config from scratch on, the .config will be deleted automaticly.


How does it work:
*****************

The trick of all is a framworking program, that means adding binaries or scripts without 
touching the real program. The program starts like if you are starting a  make config, but at that point 
where it wants an input from you, the function auto_conf gets called with that option-question
as a parameter. We are comparing this option with in a list manual-written
Kconfig option. Each of those options in the list has its own script which will be 
executed in parallel by accordance. For putting an option in the rules_list you need
the Option and a script that does the work for the option and then gives a value
to the stout. This value will be redirected through a pipe to our main program which will
write the config-name for the option into the .config file. 




How to add a rule:
*******************


The basic of the script is that it must give an answer to stdout. 
Since the rules_list is written in xml there are some conditions for adding rules.
To add a rule (for the specified option), you have to know first the option name
and the name of the menu that contains it. 
The easiest way, to do this, is to run make menuconfig, and see in which menu or submenu your option belongs to. 
Each of those has its own XML-Tag:


<rules>: beginnging of the list.

<menu name="menu name" must_have=" number ">:
	    Has the attribute "name" and "must_have". In attribute "name" the name of the menu should be written.
	    Attribute "must_have" shows the min. number of option, that in a menu should be choosen for a proper Kernel. 
	    <menu> can contains options or submenus(the same as <menu>). 

<option name="option name"> rule </option>
 	    In the attribut name the option name should be written. And the contain of the Option Tag 
	    is the name of rule that belongs to that option.

example:

<rules>
      <menu name="Networking support" must_have="1">
         <option name="Networking support">egrep1.pm "Network|Ethernet"</option>
         <menu name="Networking menus">
            <option name="Packet socket">yes1.pm</option>
            <option name="Packet socket: mmapped IO">yes1.pm</option>
	</menu>
      </menu>
</rules>


How to make a rule
*******************

A rule can be either a script or binary or... The main job is to 
give out an answer to stout for the actually option-question, it doesn't matter
how.
 
We have three types of answer:

sym-answers:     either y, n, m or \n.

string-answer:   can be maximal 128 characters

option-answer: 	 By the manual configuration normally you have to type an number
		 but a rule for an option should give out an y, if it want to be choosen. 
		




For example:    the option is "Networking Support"
		the program looks in the our list (which is called rules_list)
		to find the "Networking Support" and if this option is in there,
		a certain script (which we call it a rule)  will be executed. 
		In this example the script name is hw_grep1.pm which 
		reads a given Parameter and searches for this Parameter,
		lspci and dmesg with the help of grep. In this Case the Parameter 
		will be "Ethernet|Network".
		
		hw_grep1.pm:

		$found='';
		$found=`lspci | grep "@ARGV"`;
		if($found ne '') {
        		print("y\n");
		}
		else {
        		$found=`grep -E "@ARGV" /var/log/dmesg `;
        		if($found ne ''){
                		print("y\n");
        		}
        		else {
		                print("n\n");
        		}
		}
		1;

		
			    

		
		This script checks if there is an Ethernet or 
		a Network card  on the target System.
		If it is true, it gives  in this case a 'y' to stdout. 
		And for some options there can't be any script-rules, for instance software such as FTP or TCPIP etc...,
		those question either get answered as 'build in' or as 'module'.
		!! the answers must always have a '\n' at the end

The rule-binary should be copied in the directory <KERNELVERSION>/scripts/kconfig/rules/



Messages:
*******************

When the amount of needed Options in some menus are not choosen,
messages will be given out in the stdout, at the end of the configuration.
Containig Name of the menus.

This can be happen:

1. if for some options they rules are not applied. The reason for that is for some Hardware Option there is no rule.

2. if your System doesn't support the Hardware i.e. you don't have an ethernet Card.

In this case either your upgrade the autoconfig with rules or your contact me. 

If you are getting messages please include the following information:

1. a copy of your lspci, /proc/cpuinfo and /var/log/dmesg

2. a copy of your messages



TO DO:
*******************

1. The Framework has to be extend for the Systems that aren't supported.

2 .A way to ask for the Hardware-Devices directly from the I/O.
 

Contact:
*******************

Suggestion and comments are welcome. 

Email: Ahmad Reza Cheraghi <a_r_cheraghi@yahoo.com>

[-- Attachment #4: 1469308934-autoconfig_0_1_patch.tgz --]
[-- Type: application/x-gtar, Size: 14904 bytes --]