SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
You can get rid of them by not compiling unwanted modules in the first place. Run "make config" or "make menuconfig" or "make xconfig" to trim down tour kernel build by disabling the functionality of which you think it is unwanted.
Note that unneeded modules do not use up memory - they are only loaded into RAM when needed by the kernel (hotplug is one of the methods of determining what modules should be loaded on boot).
I agree it can be difficult to get your system trimmed. I generally start from the hardware standpoint. I use the lspci -vv to get system information. Or use systemrescuecd aidat option to get all system information. With this data at hand you can easily trim your config for hardware needs.
As from a sub systems configuration. That would be dictated by how your system is used. The network configuration options is a good place to start. Trim the options that you think will not be needed. Of course you would need tcp/ip but probably not atalk protocol unless you are communicating with a MAC OS. Many other areas you can trim, just note what protocol you will need or possibly need.
Filesystems are another place you can trim rather easily as you should know what you will be using.
Just document your changes and there resultant. Sure your config will point this out but a log will assist you by providing a trail that you can reflect on.
(Hint: Once you get it bootable, use the same config file for the revisions. Then just reconfig, make, make modules_install. It's fairly quick then.)
But always have a 'good' kernel to boot to in case the 'new' kernel fails you.
I always prefer to first use "make oldconfig" when I go to a new kernel level. Instead of getting the defaults for any new options, you get the chance to change them - say all the (new) "M" selections to "N".
Saves a bit of leg-work later when in the config.
And yes, no-one in their right mind should over-write a known good kernel image. Delete it later when you are happy with the new guy.
I like the idea of a log (gwsandvik), and I used the oldconfig to get the kernel working.
However consider this. ACPI was being a ***** (insert your favourite expletive) to set up. All options were selected in the ACPI section and it still would not work, I selected something completely unrelated in the sound drivers section (alsa oss compatibility I think) and ACPI started to work.
This is what makes me think that a there must be an easier way, for example if livecd's and most distributions can autodetect hardware and other operating systems on your computer, surely they could output this information in a format that "make (config, menuconfig, xconfig)" could read, after all it is only a plain text file, this along with a script that asks questions such as "Do you use your computer to watch TV?"
Am I just living in cloud cuckoo land or is this possible?
Or could it be that the kernel is just so complicated as it evolved that way?
Could it be time for a shake up, for example, a start would be; "Your computer has i686 architecture you will not need isa bus support so this will not be shown." There must be an awful lot of architecture specific options in the kernel.
I know this is a bit of a rant, and as I am not a programmer, completely irrelevant, however I do believe that life should be as simple as possible, and this is one of those things that could be simpler.
Many thanks again, the log is a good idea and the oldconfig is what I currently use.
What follows should be a rant, which was logical and entertaining, but the forum ate it when I tried to post it, so here is a short version, which is likely to be less logical and entertaining.
I now have ACPI working, but although all options were selected in power management / ACPI I needed to select an option in sound drivers / ALSA for ACPI to work.
This is just plain wrong.
Many hardware options are specific to architectures eg. I would not think that there is a computer out there which is i686 that has an isa bus.
So why do the kernel configuration programs not take their information from the computer not the operator, after all if live cd's can autodetect so can the kernel configuration program?
Any way I know this is probably caused by evolution of the kernel, but that does not mean it is right. As I cannot program for peanuts, this would be beyond me, but there must be a simpler way after all, all the tools are already in place, they just need to be put in a more logical order.
It appears it was not eaten after all, and now you know that I am prone to stretch the truth as the previous article was neither entertaining or logical.
I got a question for you guys. Every once in a while when I am through doing a bunch of compiling and recompiling because I well know what it is like to not have the little ******* boot, I get this message that says something to the equivelant of "Something in Lilo EDBA is overlapping something else". Has anyone had any experience like this and if so can anyone tell me what it means and how not to do it again. Hasn't happened in a while so I don't know the exact error message but it's pretty obvious if you got it and the kernel just hangs.