[SLE] Insane Uses for Perfectly Sane Tools
I was sitting here at home, compiling a new kernel for my machine (2.3.48), and I thought to myself, "Jon, there's got to be a better way to do this than `make menuconfig' or `make xconfig'. The kernel source tree is a great thing, also a very *large* thing, and difficult to manage. I was just wondering if it would be possible to use something like the hwdetect utility to recommend a `safe' and an `aggressive' kernel configuration. `safe' would be no non-experimental code, and `aggressive' would have experimental options turned on, like support for the ALi and VIA Super-7 chipsets and USB/IEEE1394 options. The stock SuSE kernels are great, but a hobbiest like myself still wants to play with things, but may still not have the foggiest idea what VIA82CXXX support is for. That's where hwdetect (or the like) would come in handy; find the VIA82CXXX chipset on the motherboard, correlate it with a .config option, and offer it to the user. It's just a thought, but I figured that somebody might think the same thing ;). What do *you* think? Is it worth slapping together? -=|JP|=- Jon Pennington | Atipa Linux Solutions -o) jpennington@atipa.com | http://www.atipa.com /\\ Kansas City, MO, USA | 816-241-2641 x121 _\_V -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
On Fri, 3 Mar 2000, Jon Pennington wrote: jp> I was sitting here at home, compiling a new kernel for my machine jp> (2.3.48), and I thought to myself, "Jon, there's got to be a better way to jp> do this than `make menuconfig' or `make xconfig'. The kernel source tree jp> is a great thing, also a very *large* thing, and difficult to manage. jp> jp> I was just wondering if it would be possible to use something like the jp> hwdetect utility to recommend a `safe' and an `aggressive' kernel jp> configuration. `safe' would be no non-experimental code, and `aggressive' jp> would have experimental options turned on, like support for the ALi and jp> VIA Super-7 chipsets and USB/IEEE1394 options. jp> jp> The stock SuSE kernels are great, but a hobbiest like myself still wants jp> to play with things, but may still not have the foggiest idea what jp> VIA82CXXX support is for. That's where hwdetect (or the like) would come jp> in handy; find the VIA82CXXX chipset on the motherboard, correlate it with jp> a .config option, and offer it to the user. It's just a thought, but I jp> figured that somebody might think the same thing ;). jp> jp> What do *you* think? Is it worth slapping together? jp> You know, this sounds like an absolutely great project, I wouldn't mind getting involved with something like this myself. jp> -=|JP|=- jp> Jon Pennington | Atipa Linux Solutions -o) jp> jpennington@atipa.com | http://www.atipa.com /\\ jp> Kansas City, MO, USA | 816-241-2641 x121 _\_V jp> jp> jp> -- S.Toms - tomas@primenet.com - www.primenet.com/~tomas SuSE Linux v6.3+ - Kernel 2.2.14 The Killer Ducks are coming!!! -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Jon Pennington wrote: Hi Jon,
I was sitting here at home, compiling a new kernel for my machine (2.3.48), and I thought to myself, "Jon, there's got to be a better way to do this than `make menuconfig' or `make xconfig'. The kernel source tree is a great thing, also a very *large* thing, and difficult to manage.
truly said. ;-)
I was just wondering if it would be possible to use something like the hwdetect utility to recommend a `safe' and an `aggressive' kernel configuration. `safe' would be no non-experimental code, and `aggressive' would have experimental options turned on, like support for the ALi and VIA Super-7 chipsets and USB/IEEE1394 options.
I don't know wether that's realy doable. There are so many options (i.e. network, routing, tunneling to speak of a few) that probably can't be guessed. Starting to think along your idea, I'd suggest to enhance "menuconfig / xconfig" in a way that a further choice "auto(detect)" appears were sensible / possible. This would solve the problem you metion below as well. Don't know how to do this, but I consider the value of something like this high. Juergen
The stock SuSE kernels are great, but a hobbiest like myself still wants to play with things, but may still not have the foggiest idea what VIA82CXXX support is for. That's where hwdetect (or the like) would come in handy; find the VIA82CXXX chipset on the motherboard, correlate it with a .config option, and offer it to the user. It's just a thought, but I figured that somebody might think the same thing ;).
What do *you* think? Is it worth slapping together?
-=|JP|=- Jon Pennington | Atipa Linux Solutions -o) jpennington@atipa.com | http://www.atipa.com /\\ Kansas City, MO, USA | 816-241-2641 x121 _\_V
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
-- =========================================== __ _ Juergen Braukmann juergen.braukmann@gmx.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu | /\\ /__/ / _ \/ // /\ \/ / ===========================================_\_v __/_/_//_/\_,_/ /_/\_\ -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
* Jon Pennington (jpennington@atipa.com) [20000304 02:46]:
The stock SuSE kernels are great, but a hobbiest like myself still wants to play with things, but may still not have the foggiest idea what VIA82CXXX support is for. That's where hwdetect (or the like) would come in handy; find the VIA82CXXX chipset on the motherboard, correlate it with a .config option, and offer it to the user. It's just a thought, but I figured that somebody might think the same thing ;).
That definitely sounds neat ;-) But I don't think we'll offer that. We're on
the contrary working to reduce the need for a self compiled kernel
(possibly to zero). The reason is simply that we can't support kernels with
unknown configuration (the possible number of permutations is
unsupportable).
And a number of options aren't for the faint of heart (like write access to
NTFS partitions), so even offering them would be placing a loaded gun in
their hands.
So in conclusion, I'd say this would be a fine private project but not
something we should support via YaST. Mind you, this is strictly my private
opinion (though privately I'd also like that feature :).
Philipp
--
Philipp Thomas
On Sat, 04 Mar 2000, Philipp Thomas wrote:
That definitely sounds neat ;-) But I don't think we'll offer that. We're on the contrary working to reduce the need for a self compiled kernel (possibly to zero). The reason is simply that we can't support kernels with unknown configuration (the possible number of permutations is unsupportable).
I understand fully. I've been watching how the stock kernel has been growing, and appreciate SuSE's policy and standpoint on the issue. But as Tim "The Tool Man" Taylor would say, "MORE POWER!"
And a number of options aren't for the faint of heart (like write access to NTFS partitions), so even offering them would be placing a loaded gun in their hands.
Perhaps I should clarify my intent; The network, file system, and other, best-untouched options could be left out of the tuning process. Perhaps the script(s) would only change the hardware configuration to suit the needs of a given PC. The networking options would stay the same between all of the kernels (not unlike they are now), but my Athlon at work would have a different configuration from my K6-III PC at home where it counts. Maybe an even better idea than that would be a script that would automatically generate a hardware list, but it would be *totally* up to the user to see if he/she wanted to enable the options. A simple PERL script (I *say* that, but have no idea when it comes to complexity) that would lspci and pnpdump, sort the information, and add generic headers and footers like: * We have detected the following hardware on your system: AMD Athlon(tm) Processor We recommend the following options: Processor type and features ---> (Pentium/K6/TSC) Processor family * We have detected the following hardware on your system: Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] We recommend the following options: Sound ---> <M> Sound card support <M> Creative Ensoniq AudioPCI 97 (ES1371) * We have detected the following hardware on your system: VGA compatible controller: ATI Technologies Inc Rage XL AGP We recommend the following options: Processor type and features ---> [*] MTRR (Memory Type Range Register) support Character devices ---> <M> /dev/agpgart (AGP Support) (EXPERIMENTAL) [*] AMD Irongate support It could poll the item descriptions directly from the same files that menuconfig does (as I have here, a la X buffer ;), and make it really easy. The complicated part would probably be having someone do the research to keep track of all of the new hardware options, thier identifiers, and making sure that the script knows what to do with them. -- -=|JP|=- Jon Pennington | Atipa Linux Solutions -o) jpennington@atipa.com | Kansas City, MO /\\ 816-241-2641 x121 | http://www.atipa.com _\_V -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
the easiest way to do this is leave everything modularised, as in the installation kernels, so you don't need to recompile at all. Agreed that some sort of hardware detection is valuable - presumably this is what hwdetect is about. The test a couple of weeks back seemed to me to be about comparing what hwdetect could tell about a system versus what the users knew to be true. At least on my stsrem hwdetect was 100% accurate. On Fri, 3 Mar 2000, Jon Pennington wrote:
I was sitting here at home, compiling a new kernel for my machine (2.3.48), and I thought to myself, "Jon, there's got to be a better way to do this than `make menuconfig' or `make xconfig'. The kernel source tree is a great thing, also a very *large* thing, and difficult to manage.
I was just wondering if it would be possible to use something like the hwdetect utility to recommend a `safe' and an `aggressive' kernel configuration. `safe' would be no non-experimental code, and `aggressive' would have experimental options turned on, like support for the ALi and VIA Super-7 chipsets and USB/IEEE1394 options.
The stock SuSE kernels are great, but a hobbiest like myself still wants to play with things, but may still not have the foggiest idea what VIA82CXXX support is for. That's where hwdetect (or the like) would come in handy; find the VIA82CXXX chipset on the motherboard, correlate it with a .config option, and offer it to the user. It's just a thought, but I figured that somebody might think the same thing ;).
What do *you* think? Is it worth slapping together?
-=|JP|=- Jon Pennington | Atipa Linux Solutions -o) jpennington@atipa.com | http://www.atipa.com /\\ Kansas City, MO, USA | 816-241-2641 x121 _\_V
-- This sig brought to you by SuSE 6.3 and sendmail. Linux - you know it makes sense. -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
On Sat, 04 Mar 2000, wulfie wrote:
the easiest way to do this is leave everything modularised, as in the installation kernels, so you don't need to recompile at all.
Agreed that some sort of hardware detection is valuable - presumably this is what hwdetect is about. The test a couple of weeks back seemed to me to be about comparing what hwdetect could tell about a system versus what the users knew to be true. At least on my stsrem hwdetect was 100% accurate.
The problem is that you cannot modularize support for an IDE chipset, such as VIA Apollo, AMD Viper, ALi Aladdin, or what have you. And including all of these options into a single kernel is impossible. My hats off, btw, to the SuSE team for coming up with the `Special IDE' kernel ;). It's still a bit generic, though. -- -=|JP|=- Jon Pennington | Atipa Linux Solutions -o) jpennington@atipa.com | Kansas City, MO /\\ 816-241-2641 x121 | http://www.atipa.com _\_V -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
participants (5)
-
jpennington＠atipa.com -
juergen.braukmann＠ruhr-west.de -
pthomas＠suse.de -
tomas＠primenet.com -
wulfie＠wulfric7.co.uk