--1421910094-2002581036-931865670=:27579
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Steffen.
> Okay, there were some good ideas about all the zImage and
> bzImage stuff and I'll try to extend my script with all this in
> my mind and than all of you can have look at it, test it and say
> me what you think of it.
>>>> Q> if grep CONFIG_MODULES=y .config > /dev/null ; then
>>>> Q> make modules modules_install
>>>> Q> fi
>>> This might be a good idea, I haven't thought of people not using
>>> modules.
>> Try doing the "make modules" with modules disabled, and you soon
>> discover that it reports an error...
> So, it should get in definitely.
If you want the script to work on all systems, then yes...
>> I have recently set up several different 386dx/{16,20,25} based
>> systems as print servers and inter-network-segment gateways for
>> a school, and I would hate to compile a modern Linux kernel on
>> one of those systems.
>> Perhaps the script could be split into two parts, one to run on
>> the target system to determine the required configuration, and
>> one to run on the compilation system to control the compilation
>> process - and which, if used in mode 2, produces a tarball ready
>> to be extracted on the target system that drops the modules in
>> the relevant directory and puts the kernel image in its relevant
>> directory...
> Yes. That's a possibility. But, the first is to get this working
> on the same computer. To name it:
> 1. find a way to determine as much as possible about the current
> hardware.
The attached bash script is how I would start doing that...
> 2. find some questions that are easy to answer and completes the
> knowledge about the hardware.
> 3. sort all options by the criteria: MUST SET, MUST NOT SET,
> MAYBE SET.
> 4. Let the user choose options that MAYBE SET.
> 5. You've got your configuration.
Note that many hardware options can only be auto-detected if the
relevant driver is loaded. For example, the attached script only
detects the printer port if the RUNNING kernel currently includes
support for the printer port.
This implies that the autoconfig script needs to follow something
like the following algorithm for each option - I'll use parallel
port support for this example, but it applies to many other options
in a similar manner as well:
1. Is there a printer port listed in /proc/ioports here? If so,
enable this option and finish, else go to step 2.
2. Can we determine that the driver for the printer port is
currently loaded? If so, go to step 3, else go to step 5.
3. Is the driver for the printer port currently loaded? If so,
disable this option and finish, else go to step 4.
4. Can we load the driver for the printer port as a module? If
so, load it and go to step 1, else go to step 5.
5. Ask the user whether to include parallel port support.
>>> E.g.: I wanted to use my SB PCI 64V sound card and I'm STILL
>>> not sure which options I have to set. There are so many
>>> contradicting statements in the internet.
>> The big problem with that idea is keeping the database up to date,
>> unless you plan on buying one of every different card that comes
>> out...
> I was thinking of a database which many people maintain. For
> example: one person finds out no matter how which settings he
> needs for his new component X and he fills out a template
> provided that generates an email which will be a new entry in
> the database.
How does one deal with the fact that the settings that work on one
configuration do NOT work on another?
As an example of this, take my two systems. I have a USR Sportster
33k6/VoiceFax modem, and I need to set it up DIFFERENTLY for the two
systems. OK, both have it set for COM3 at 0x3E8, but on one, I need to
set it to use IRQ5 and on the other I need to set it to use IRQ2/9.
> Okay, but all that is in the future. First of all I want to do
> it in the simple way: Starting to work after xconfig. If that is
> finished I would like to extend it in this direction.
I have to admit that I don't use xconfig myself, much preferring
menuconfig, but that's just personal preference...
>> One other thought - is your script going to be i386 only?
> No, as long as there is no real good reason for that I want to
> keep it generic.
Good - but note that there will be (probably large) parts of it that
are architecture-dependant - the processor model detection for
starters...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
--1421910094-2002581036-931865670=:27579
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=config
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9907131234300.27579@ps.cus.umist.ac.uk>
Content-Description:
Content-Disposition: attachment; filename=config
IyEvYmluL2Jhc2gNCmZ1bmN0aW9uIGdldCgpIHsNCiAgICBsb2NhbCBYPWBn
cmVwICIkMSIgL3Byb2MvY3B1aW5mbyB8IGN1dCAtZCA6IC1mIDItIHwgdHIg
LXMgJ1x0JyAnICcgXA0KCQkJICAgICB8IHRyIEEtWiBhLXogfCBzZWQgJ3Mv
WygpXS8vZycgfCBzb3J0IC11YA0KDQogICAgaWYgWyAkIyAtZXEgMiBdOyB0
aGVuDQoJWD1gZWNobyAkWCB8IHRyICcgJyAnXG4nIHwgZWdyZXAgIl4kMiIg
fCB0ciAnXG4nICcgJ2ANCiAgICBmaQ0KICAgIGVjaG8gJFgNCn0NCmZ1bmN0
aW9uIHNob3coKSB7DQogICAgaWYgWyAteiAiJDEiIF07IHRoZW4NCglwcmlu
dGYgJyAgICAlLTM0cyAgJXNcbicgQ09ORklHXyQyPSQzICIkNSINCiAgICBl
bHNlDQoJcHJpbnRmICcgICAgJS0zNHMgICVzXG4nIENPTkZJR18kMj0kNCAi
JDUiDQogICAgZmkNCn0NClZFTkRPUj1gZ2V0IHZlbmRvcl9pZGANClBST0NF
U1NPUj1gZ2V0ICdtb2RlbCBuYW1lJ2ANCmlmIFsgYGdyZXAgcHJvY2Vzc29y
IC9wcm9jL2NwdWluZm8gfCB3YyAtbGAgLWd0IDEgXTsgdGhlbg0KICAgIFNN
UD1zbXANCmVsc2UNCiAgICBTTVA9JycNCmZpDQpBUElDPWBnZXQgZmxhZ3Mg
YXBpY2ANCkZQVT1gZ2V0IGZsYWdzIGZwdWANCk1NWD1gZ2V0IGZsYWdzIG1t
eGANCk1UUlI9YGdldCBmbGFncyBtdHJyYA0KVFNDPWBnZXQgZmxhZ3MgdHNj
YA0KaWYgZWNobyAkUFJPQ0VTU09SIHwgZ3JlcCAnWzM0XTg2JyA+IC9kZXYv
bnVsbCA7IHRoZW4NCiAgICBDUFU9YGVjaG8gJENQVSB8IHNlZCAncy9eLipc
KFszNF04NlwpLiokL1wxLydgDQplbHNlDQogICAgY2FzZSAkVkVORE9SIGlu
DQoJYXV0aGVudGljYW1kKQlpZiBlY2hvICRQUk9DRVNTT1IgfCBncmVwIEs3
ID4gL2Rldi9udWxsIDsgdGhlbg0KCQkJICAgIENQVT02ODYNCgkJCWVsc2UN
CgkJCSAgICBDUFU9NTg2VFNDDQoJCQlmaQ0KCQkJOzsNCgljeXJpeGluc3Rl
YWQpCUNQVT01ODYNCgkJCTs7DQoJZ2VudWluZWludGVsKQlpZiBlY2hvICRQ
Uk9DRVNTT1IgfCBncmVwICdwZW50aXVtIGlpJyA+IC9kZXYvbnVsbCA7IHRo
ZW4NCgkJCSAgICBDUFU9Njg2DQoJCQllbGlmIGVjaG8gJFBST0NFU1NPUiB8
IGdyZXAgJ3BlbnRpdW0gcHJvJyA+IC9kZXYvbnVsbCA7IHRoZW4NCgkJCSAg
ICBDUFU9Njg2DQoJCQllbGlmIFsgLW4gIiRUU0MiIF07IHRoZW4NCgkJCSAg
ICBDUFU9NTg2VFNDDQoJCQllbHNlDQoJCQkgICAgQ1BVPTU4Ng0KCQkJZmkN
CgkJCTs7DQogICAgZXNhYw0KZmkNClBDST1gbHMgLTEgL3Byb2MvcGNpIDI+
IC9kZXYvbnVsbGANCk1DQT1gbHMgLTEgL3Byb2MvbWNhIDI+IC9kZXYvbnVs
bGANCkNPTT1gZ3JlcCAnIHNlcmlhbCcgL3Byb2MvaW9wb3J0c2ANCkxQVD1g
Z3JlcCAnIGxwJyAvcHJvYy9pb3BvcnRzYA0KZWNobw0KZWNobyBCYXNlZCBv
biB0aGUgYXZhaWxhYmxlIGluZm9ybWF0aW9uLCB0aGUgZm9sbG93aW5nIExp
bnV4IGtlcm5lbA0KZWNobyBjb25maWd1cmF0aW9uIGlzIGFwcGxpY2FibGUg
dG8gdGhpcyBzeXN0ZW06DQplY2hvDQpzaG93ICJDUFUiICAgJHtDUFV9ICAg
ICAgICAgbiB5ICJQcm9jZXNzb3IgKCRQUk9DRVNTT1IpIg0Kc2hvdyAiJEZQ
VSIgIE1BVEhfRU1VTEFUSU9OIHkgbiAnTWF0aHMgQ29wcm9jZXNzb3IgZW11
bGF0aW9uJw0Kc2hvdyAiJE1UUlIiIE1UUlIgICAgICAgICAgIG4geSAnTWVt
b3J5IFR5cGUgUmFuZ2UgUmVnaXN0ZXInDQpzaG93ICIkU01QIiAgU01QICAg
ICAgICAgICAgbiB5ICdTeW1tZXRyaWMgTXVsdGktUHJvY2Vzc29yJyAgIA0K
ZWNobw0Kc2hvdyAiJFBDSSIgIFBDSSAgICAgICAgICAgIG4geSAnUENJIGJ1
cycNCnNob3cgIiRNQ0EiICBNQ0EgICAgICAgICAgICBuIHkgJ01DQSBidXMn
DQplY2hvICcgICAgICAgOicNCnNob3cgIiRMUFQiICBQQVJQT1JUICAgICAg
ICBuIHkgJ1BhcmFsbGVsIHBvcnQgc3VwcG9ydCcNCnNob3cgIiRDT00iICBT
RVJJQUwgICAgICAgICBuIHkgJ1NlcmlhbCBwb3J0IHN1cHBvcnQnDQpleGl0
IDANCg==
--1421910094-2002581036-931865670=:27579--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/