[gentoo-user] A pared down kernel config

[gentoo-user] A pared down kernel config

[reader]

Configuring a new kernel is a dreaded task here.  It seems I walk
through a bewildering array of stuff that when pressing F1 on them I
get more bewildering information I barely understand a word of.

For 8 or 9 yrs now I've mostly skirted the issue by using defaults.  

I hnow the shortcoming is mine but still it is a massive amount of
knowledge needed to really know what most of those settings do.

Of course I know the easy ones but it appears thats never enough to
walk through and end up with a pared down but fully usable kernel.

In the end I usually just `genkernel all' and let ten thousand modules
be made and forget it.

I'd like to know more... enough so that when kernel config time rolls
around its not a frustrating and time consuming chore ... unless I go
the genkernel route.

I see plenty of howtos out there about kernel configuration but the
ones I've scanned or used take you through the steps but never really
teach you how to understand what all those setting do or entail.

I also realize that the kernel is a moving target and configurations
change literally with every kernel.  But there must be a major base of
settings that change only slowly.  Ones a user can learn enough about
that it isn't such a bewildering experience to try to get the settings
right in one or two goes.

And of course the kicker is that I'd like to learn this without weeks
and weeks of pounding away at it.

My current quest involved getting a kernel with full barrel iptables
and conn_track settings in place.  The usual problem is that the howtos
are dealing with a much older (in kernel devel time) kernel that
actually has different or not all the setting currently available.

Can someone steer me to a more `in depth' tutorial?  Or to something
they've found to really throw some light the chore?  Not necessarily
about iptables but just the general chore of configuring a kernel
wisely. 

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] A pared down kernel config

[Hemmann, Volker Armin]

On Samstag, 5. Januar 2008, reader@newsguy.com wrote:

you want to read this:
http://www.kroah.com/lkn/

configuring a kernel is a matter of minutes. And seconds, if you just copy 
over the old config and do 'make oldconfig'.

It is not hard - the first time read all the help texts and think about them. 
That is the hardest part. Do you really need I2O? Almost nobody does. I2C? 
Yes. ... 

-- 
Conclusions 
 In a straight-up fight, the Empire squashes the Federation like a bug. Even 
with its numerical advantage removed, the Empire would still squash the 
Federation like a bug. Accept it. -Michael Wong 
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: A pared down kernel config

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

> On Samstag, 5. Januar 2008, reader@newsguy.com wrote:
>
> you want to read this:
> http://www.kroah.com/lkn/

Thanks... I'm getting started now.

> configuring a kernel is a matter of minutes. And seconds, if you just copy 
> over the old config and do 'make oldconfig'.

Yeah if you  do that... but if you want to go through and look at all the
different stuff and try to understand.... the minutes, and seconds
theory is history.

> It is not hard - the first time read all the help texts and think about them. 
> That is the hardest part. Do you really need I2O? Almost nobody does. I2C? 
> Yes. ... 

You are clearly on a much different plain than I.
`Read all the help texts and think about them.'  If you can do that and
feel you've understood even a small portion of it, that puts you way
up the knowledge ladder compared to us lesser endowed.

Unless you mean all those places that say `if unsure just say yes'.
Or better yet those that say:
`There is no help available for this kernel option.'

Here is a good one.
 CONFIG_PARAVIRT:                                                    
  |                                                                  
  | Paravirtualization is a way of running multiple instances of     
  | Linux on the same machine, under a hypervisor.  This option      
  | changes the kernel so it can modify itself when it is run        
  | under a hypervisor, improving performance significantly.         
  | However, when run without a hypervisor the kernel is             
  | theoretically slower.  If in doubt, say N.        

Unless you are talking about the last `If in doubt...'
Then you are stuck figuring out what on earth a hypervisor is.

Or here:

  | CONFIG_HPET_TIMER:                                                 
  |                                                                    
  | This enables the use of the HPET for the kernel's internal timer.  
  | HPET is the next generation timer replacing legacy 8254s.          
  | You can safely choose Y here.  However, HPET will only be          
  | activated if the platform and the BIOS support this feature.       
  | Otherwise the 8254 will be used for timing services. 

Unless you mean `You can safely choose Y here' then you have a few
days work figuring out what any of that means.

This goes on and on through the menus..
So no.. I don't think we are dealing with minutes here.

If you mean you can get it done if you just skip all of that.... then
yes it might be minutes.

If you wanted to pare down all the junk that is in a default
config... now you are taking days even weeks to get a handle on that.

At least it would be for the `intellectually challenged' like me..

Thanks again... that looks like a good start.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Hemmann, Volker Armin]

On Samstag, 5. Januar 2008, reader@newsguy.com wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:
> > On Samstag, 5. Januar 2008, reader@newsguy.com wrote:
> >
> > you want to read this:
> > http://www.kroah.com/lkn/
>
> Thanks... I'm getting started now.
>
> > configuring a kernel is a matter of minutes. And seconds, if you just
> > copy over the old config and do 'make oldconfig'.
>
> Yeah if you  do that... but if you want to go through and look at all the
> different stuff and try to understand.... the minutes, and seconds
> theory is history.

even than it does not take that ling.

>
> > It is not hard - the first time read all the help texts and think about
> > them. That is the hardest part. Do you really need I2O? Almost nobody
> > does. I2C? Yes. ...
>
> You are clearly on a much different plain than I.
> `Read all the help texts and think about them.'  If you can do that and
> feel you've understood even a small portion of it, that puts you way
> up the knowledge ladder compared to us lesser endowed.

you have to start somewhere. When compiled my first kernel (2.2.14) nobody 
hold my hand - and I needed several tries to get a booting one. But over the 
years a lot of experience accumulates. Do I need fibrechannel? Certainly not.

>
> Unless you mean all those places that say `if unsure just say yes'.

is there better help? If you don't know what to do, say yes. Easy!

> Or better yet those that say:
> `There is no help available for this kernel option.'

there are only very few of those - and usually it is best to let them 
unchanged.
>
> Here is a good one.
>
>  CONFIG_PARAVIRT:
>   | Paravirtualization is a way of running multiple instances of
>   | Linux on the same machine, under a hypervisor.  This option
>   | changes the kernel so it can modify itself when it is run
>   | under a hypervisor, improving performance significantly.
>   | However, when run without a hypervisor the kernel is
>   | theoretically slower.  If in doubt, say N.
>
> Unless you are talking about the last `If in doubt...'
> Then you are stuck figuring out what on earth a hypervisor is.

Nope, the helptext tells you exactly what it does. And it tells you, that you 
can say no, if you don't know what to do here.

>
> Or here:
>   | CONFIG_HPET_TIMER:
>   |
>   | This enables the use of the HPET for the kernel's internal timer.
>   | HPET is the next generation timer replacing legacy 8254s.
>   | You can safely choose Y here.  However, HPET will only be
>   | activated if the platform and the BIOS support this feature.
>   | Otherwise the 8254 will be used for timing services.
>
> Unless you mean `You can safely choose Y here' then you have a few
> days work figuring out what any of that means.

no, you have some SECONDS to figure it out:
gg:hpet
(with konqueror).
And what is wrong with 'you can safely choose Y here'? It tells you that it 
does not harm to turn it on. So why turn it off? Why think about it, if you 
don't know what a hpet is (btw, hpet is also explained in detail in the 
Documentation directory. a single grep -R hpet /usr/src/linux/Documentation 
would show you where).

>
> This goes on and on through the menus..
> So no.. I don't think we are dealing with minutes here.

you can, if you accept that you should use the recommended choice, expet when 
ou knmow what you are doing.

>
> If you mean you can get it done if you just skip all of that.... then
> yes it might be minutes.
>
> If you wanted to pare down all the junk that is in a default
> config... now you are taking days even weeks to get a handle on that.

to de-junk a default config - even if you don't know what you do, is in realm 
of half an hour to an hour. If you read everything.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: A pared down kernel config

[reader]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> writes:

I think this is heading in direction different from what I intended.

You seem to be arguing that it can be done quickly... I don't disagree
with you.  If like you say you mostly follow what ever is default
unless you know what you are doing.  But if that is what you do then
genkernel is even quicker... Not in compile time but to decide is not
more than `genkernal all'.  

So I haven't been saying it can't be done quickly. (If you depend
largely on defaults).  The os designers have seen to it that the
defaults will produce a working kernel. And they are pretty good at
it. 

I'm not complaining that the process provided is overly hard. (If you
mostly follow defaults)

In the very first post I said:

>> For 8 or 9 yrs now I've mostly skirted the issue by using defaults.

That is all you suggest too.  Skirt the issue by using defaults. 

>> If you wanted to pare down all the junk that is in a default
>> config... now you are taking days even weeks to get a handle on that.
>
> to de-junk a default config - even if you don't know what you do, is
> in realm of half an hour to an hour. If you read everything.

Do you have a de-junked .config that I can diff against the
default.. it would be a way to see what kinds of things get dropped.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Alan McKinnon]

On Saturday 05 January 2008, reader@newsguy.com wrote:
> > to de-junk a default config - even if you don't know what you do,
> > is in realm of half an hour to an hour. If you read everything.
>
> Do you have a de-junked .config that I can diff against the
> default.. it would be a way to see what kinds of things get dropped.

Drivers for stuff you don't need and you will likely never use. Like ham 
radio stuff, v4linux (first version), I20, on a notebook all the 
enterprise-grade connect-a-machine-to-storage-stuff like iSCSI and 
Infiniband, all of ISA and MCA and the pre-pci bus drivers, old disk 
types like mfm and on modern boards usually even IDE as well. 

Removing all these unused drivers is the single largest improvement in 
reducing kernel size. The general rule with drivers is that if you are 
familiar with YOUR hardware and you've never heard of something in the 
config then you don't have it and don't need it :-)

Complete kernel sub-systems are a bit harder, although some are still 
obvious. Like virtualisation. I assure you that if you have never heard 
of kvm and paravirt, then you certainly don't need it.

With other stuff I usually end up leaving them in and removing things 
gradually as I compile the next kernel and learn more about stuff out 
there. If say HPET intrigues you and you want to know more, then Google 
it. Tomorrow you can do another one.

Like I said in an earlier mail, it's not an easy process. It's only easy 
if you know most of it already - like Volker. I'd guess he has long 
since forgotten what it took to learn everything he knows, so of 
course "It's obvious!"...

Comparing his and your configs is mostly pointless as your machines will 
differ considerably. The config file is >70k and even on two recent 
standard ubuntu configs the differences are over 1000 lines. Good luck 
with comparing that lot and trying to figure out what's going on :-)

alan

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: A pared down kernel config

[reader]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> On Saturday 05 January 2008, reader@newsguy.com wrote:
>> > to de-junk a default config - even if you don't know what you do,
>> > is in realm of half an hour to an hour. If you read everything.
>>
>> Do you have a de-junked .config that I can diff against the
>> default.. it would be a way to see what kinds of things get dropped.
>
> Drivers for stuff you don't need and you will likely never use. Like ham 
> radio stuff, v4linux (first version), I20, on a notebook all the 
> enterprise-grade connect-a-machine-to-storage-stuff like iSCSI and 
> Infiniband, all of ISA and MCA and the pre-pci bus drivers, old disk 
> types like mfm and on modern boards usually even IDE as well. 

Thanks... but you hit on something there that can throw you.  
  scsi stuff.  

I've never used a scsi hard drive in my life but not that long ago
linux users needed scsi support for many of the cdrom drives.  I doubt
that is still the case but it might be.  But my point is that even
when you think you know something isn't needed it might be in some
context you haven't thought of.

People in this thread speak of 2 and 3 boots and editing in between in
the same message where `5 minutes' is mentioned.  That doesn't wash.
You're way past that time frame.  But still not in the guiness book
realm I guess... hehe.

> Removing all these unused drivers is the single largest improvement in 
> reducing kernel size. The general rule with drivers is that if you are 
> familiar with YOUR hardware and you've never heard of something in the 
> config then you don't have it and don't need it :-)

Just to know more on this... Is there really any reason to worry about
kernel size... I mean in most cases with a standard desktop install?

I noticed a massive difference in drivers and modules installed
between a machine running kde and X and a hand roled kernel I
configured on nox system with just basic install.  In fact that is
what led to my post here.  But the actual kernel wasn't all that
different in size.


[...]

> Like I said in an earlier mail, 

Do you mean on this thread?  If so I must have some trouble with my
newsreader threading or something... I don't see it here.

> . . . . . . . . . . . . . . . .it's not an easy process. It's only easy 
> if you know most of it already - like Volker. I'd guess he has long 
> since forgotten what it took to learn everything he knows, so of 
> course "It's obvious!"...

Here here.  
 ... And thanks for the basic advice and comments.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: A pared down kernel config

[reader]

reader@newsguy.com writes:

>> Like I said in an earlier mail, 
>
> Do you mean on this thread?  If so I must have some trouble with my
> newsreader threading or something... I don't see it here.

Haa I see it now... and it looks like I brought up exactly some of
what you covered there (scsi).  Interesting that at least we both saw
the same thing about scsi.

Thanks for that input too.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Hemmann, Volker Armin]

On Sonntag, 6. Januar 2008, reader@newsguy.com wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> writes:
> > On Saturday 05 January 2008, reader@newsguy.com wrote:
> >> > to de-junk a default config - even if you don't know what you do,
> >> > is in realm of half an hour to an hour. If you read everything.
> >>
> >> Do you have a de-junked .config that I can diff against the
> >> default.. it would be a way to see what kinds of things get dropped.
> >
> > Drivers for stuff you don't need and you will likely never use. Like ham
> > radio stuff, v4linux (first version), I20, on a notebook all the
> > enterprise-grade connect-a-machine-to-storage-stuff like iSCSI and
> > Infiniband, all of ISA and MCA and the pre-pci bus drivers, old disk
> > types like mfm and on modern boards usually even IDE as well.
>
> Thanks... but you hit on something there that can throw you.
>   scsi stuff.

you need scsi for:
sata harddisk
sata cdroms
usb sticks
usb harddrives
usb cdroms (like in an external case)
usb card readers.

In fact, if you enable sata, scsi harddisk support is enabled automatically.

>
> I've never used a scsi hard drive in my life but not that long ago
> linux users needed scsi support for many of the cdrom drives.  

no.
You never needed scsi for 'standard' atapi cdrom drives. Once upon a time you 
needed scsi-ide emulation for burning and even that is gone.

> I doubt 
> that is still the case but it might be.  But my point is that even
> when you think you know something isn't needed it might be in some
> context you haven't thought of.

well, the scsi-usb relation is explained in the help texts.

>
> People in this thread speak of 2 and 3 boots and editing in between in
> the same message where `5 minutes' is mentioned.  That doesn't wash.
> You're way past that time frame.  But still not in the guiness book
> realm I guess... hehe.

since the kernel make system is smart, only the stuff that changed is redone. 
So 3 reboots+2recompiles are easily done in 5minutes.

>
> Just to know more on this... Is there really any reason to worry about
> kernel size... I mean in most cases with a standard desktop install?
>

yes. Bigger kernel = more cpu cache used up = slower system.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Yahya Mohammad]

> > Just to know more on this... Is there really any reason to worry about
> > kernel size... I mean in most cases with a standard desktop install?
> >
> 
> yes. Bigger kernel = more cpu cache used up = slower system.

Does all of the kernel reside in cpu cache all the time? Or can parts
of it get moved to system RAM? What about modules that are loaded from
disk?
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Jan-Hendrik Zab]

On Sun, 6 Jan 2008 10:58:12 +0400
Yahya Mohammad <mfyahya@gmail.com> wrote:

> > > Just to know more on this... Is there really any reason to worry
> > > about kernel size... I mean in most cases with a standard desktop
> > > install?
> > >
> > 
> > yes. Bigger kernel = more cpu cache used up = slower system.
> 
> Does all of the kernel reside in cpu cache all the time? Or can parts
> of it get moved to system RAM? What about modules that are loaded from
> disk?

No, it does not. The CPU caches are used differently. Partly, they
become something like read-ahead caches due to the fact that the CPU
can only read hole cache lines.

See http://lwn.net/Articles/252125/ for a good and recent documentation.

	Jan-Hendrik Zab

-- 
Jan-Hendrik Zab <jan.h.zab@gmail.com>
Tel: +49 (0)15154625819
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Alan McKinnon]

On Sunday 06 January 2008, reader@newsguy.com wrote:
> People in this thread speak of 2 and 3 boots and editing in between
> in the same message where `5 minutes' is mentioned.  That doesn't
> wash. You're way past that time frame.  But still not in the guiness
> book realm I guess... hehe.

I guess the English phrase '5 minutes' is a symlink to another longer 
phrase: 'A reasonably short period of time that doesn't cause me 
massive amounts of inconvenience'. I have a spare 2.6.23-gentoo source 
tree here with everything enabled. With no changes to the config a 
second 'make' still takes 2m29.414s

2 to 3 boots with a new kernel version, especially one where sub-systems 
like libata got moved around, sounds perfectly reasonable.
>
> > Removing all these unused drivers is the single largest improvement
> > in reducing kernel size. The general rule with drivers is that if
> > you are familiar with YOUR hardware and you've never heard of
> > something in the config then you don't have it and don't need it
> > :-)
>
> Just to know more on this... Is there really any reason to worry
> about kernel size... I mean in most cases with a standard desktop
> install?

By "kernel size" I actually meant disk space used, including it's 
modules.

Seeing as almost every other mainstream distro gives you a full-featured 
kernel with all modules included and /lib/modules/`uname -r`/ weighs in 
at around 400M, I'd say no, it's not worth worrying about.

Some people do worry about it, and that's cool for them. Some folk do 
lots of kernel testing, if they have 10 kernel versions on disk then it 
does become a factor. The beauty of gentoo is that if you don't feel 
like caring, you don't have to.

alan

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Erik]

reader@newsguy.com skrev:
> Then you are stuck figuring out what on earth a hypervisor is.
>   
Alt+F2
wp:hypervisor
ENTER

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: A pared down kernel config

[reader]

Erik <sigra@home.se> writes:

> reader@newsguy.com skrev:
>> Then you are stuck figuring out what on earth a hypervisor is.
>>   
> Alt+F2
> wp:hypervisor
> ENTER

Hey thats a pretty neat trick.  Now if I wondered if that would be
important since I plan to run a vmware application... I will take more
digging.  It mentions vmware but not clear if this is important to it.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Alan McKinnon]

On Sunday 06 January 2008, reader@newsguy.com wrote:
> Erik <sigra@home.se> writes:
> > reader@newsguy.com skrev:
> >> Then you are stuck figuring out what on earth a hypervisor is.
> >
> > Alt+F2
> > wp:hypervisor
> > ENTER
>
> Hey thats a pretty neat trick.  Now if I wondered if that would be
> important since I plan to run a vmware application... I will take
> more digging.  It mentions vmware but not clear if this is important
> to it.

No, it's not relevant in this case. vmware is a virtualisation app, but 
doesn't use a hypervisor - it's a regular application with some custom 
kernel modules. kvm, xen and (I think) qemu do use hypervisors so this 
feature needs to be in the kernel for them.

Virtualisation is a vast field covering many many different techniques, 
each with their own pros and cons. The technique vmware uses makes it 
very easy to install, use and configure your virtual machine (it's just 
a bunch of big files), but the performance frankly sucks. At the other 
extreme you get VServer which runs like a bomb but is tightly tied onto 
the host machine running it. Somewhere in the middle we have xen and 
it's simpler cousin kvm - due to hypervisors they give very good 
performance and are relatively easy to configure and maintain.

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] A pared down kernel config

[Alan McKinnon]

On Saturday 05 January 2008, reader@newsguy.com wrote:
> Configuring a new kernel is a dreaded task here.  It seems I walk
> through a bewildering array of stuff that when pressing F1 on them I
> get more bewildering information I barely understand a word of.

Ah yes. It's that way 'cause it was designed that way :-)

[snip]

> And of course the kicker is that I'd like to learn this without weeks
> and weeks of pounding away at it.

Unfortunately and in my experience, there's no easy shortcut to getting 
a sane minimal kernel config. You really do need to have at least a 
high-level understanding of what the various chunks of the kernel do so 
that you can decide to enable them or not. You need to understand what 
the various bits of hardware are - if you have never heard of iSCSI you 
will have no idea if you need it or not. It's not enough to generally 
just say "If you don't know what it is, you don't need it" as you might 
run into SCSI, and know for a fact you do not have any SCSI hardware. 
But, without it, all kinds of stuff break (like usb storage)

I know how I got my current level of knowledge - years and years of 
pounding away at it, reading thousands of howtos and web pages, only to 
have tons of it become redundant every six months. I strongly suspect 
you may have to do something similar.

> My current quest involved getting a kernel with full barrel iptables
> and conn_track settings in place.  The usual problem is that the
> howtos are dealing with a much older (in kernel devel time) kernel
> that actually has different or not all the setting currently
> available.

trial-and-error is probably your best bet. Get it working with a full 
genkernel setup. Note which modules get used in real life, start 
removing them in batches and make notes when stuff breaks

> Can someone steer me to a more `in depth' tutorial?  Or to something
> they've found to really throw some light the chore?  Not necessarily
> about iptables but just the general chore of configuring a kernel
> wisely.

I've yet to find a single resource for this. As I said above it does 
seem to be a collection of knowledge gathered from  many places over a 
long period.

There's a reason for the existence of genkernel - it's so that you don't 
have to go through all this pain and suffering, and can instead remove 
stuff a bit at a time with reasonable confidence it won;t blow up in 
your face :-)

alan

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] A pared down kernel config

[Florian Philipp]

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


On Sat, 2008-01-05 at 19:06 +0200, Alan McKinnon wrote:
> trial-and-error is probably your best bet. Get it working with a full 
> genkernel setup. Note which modules get used in real life, start 
> removing them in batches and make notes when stuff breaks
> 
> There's a reason for the existence of genkernel - it's so that you don't 
> have to go through all this pain and suffering, and can instead remove 
> stuff a bit at a time with reasonable confidence it won;t blow up in 
> your face :-)
> 

There is a fairly easy trick to get rid of pointless options like unused
drivers even if you are not sure about your hardware or the kernel
options themselves: 
Compile them as modules, then boot the new kernel. If the modules don't
get loaded (lsmod is your friend) and everything works fine, throw them
out of your configuration.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: A pared down kernel config

[reader]

Florian Philipp <lists@f_philipp.fastmail.net> writes:

>> There's a reason for the existence of genkernel - it's so that you don't 
>> have to go through all this pain and suffering, and can instead remove 
>> stuff a bit at a time with reasonable confidence it won;t blow up in 
>> your face :-)
>> 
>
> There is a fairly easy trick to get rid of pointless options like unused
> drivers even if you are not sure about your hardware or the kernel
> options themselves: 
> Compile them as modules, then boot the new kernel. If the modules don't
> get loaded (lsmod is your friend) and everything works fine, throw them
> out of your configuration.

Nice... a small question: how do you keep up with what gets installed?
Do you ferret them out at /lib/modules with cmds like 
find . -name '*.ko'

Or is there a log created at compile time.. or maybe create one like
make modules_intall >mymod.log.  Just thinking outload.

Following a `genkernal all' I saw a very big list get installed but didn't
think to log them.

I guess it would be harmless to just run the `make modules_intall' part
again and catch a list.

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] Re: A pared down kernel config

[Florian Philipp]

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


On Sun, 2008-01-06 at 17:15 -0600, reader@newsguy.com wrote:
> Florian Philipp <lists@f_philipp.fastmail.net> writes:
> 
> >> There's a reason for the existence of genkernel - it's so that you don't 
> >> have to go through all this pain and suffering, and can instead remove 
> >> stuff a bit at a time with reasonable confidence it won;t blow up in 
> >> your face :-)
> >> 
> >
> > There is a fairly easy trick to get rid of pointless options like unused
> > drivers even if you are not sure about your hardware or the kernel
> > options themselves: 
> > Compile them as modules, then boot the new kernel. If the modules don't
> > get loaded (lsmod is your friend) and everything works fine, throw them
> > out of your configuration.
> 
> Nice... a small question: how do you keep up with what gets installed?
> Do you ferret them out at /lib/modules with cmds like 
> find . -name '*.ko'
> 
> Or is there a log created at compile time.. or maybe create one like
> make modules_intall >mymod.log.  Just thinking outload.
> 
> Following a `genkernal all' I saw a very big list get installed but didn't
> think to log them.
> 
> I guess it would be harmless to just run the `make modules_intall' part
> again and catch a list.
> 

I think you search for "modprobe -l" :)

Have a nice day!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: A pared down kernel config

[reader]

Florian Philipp <lists@f_philipp.fastmail.net> writes:

>> I guess it would be harmless to just run the `make modules_intall' part
>> again and catch a list.
>> 
>
> I think you search for "modprobe -l" :)

Wow... and egad, look at this:

  modprobe -l|wc -l
  945

That is a kernel built with genkernel

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] A pared down kernel config

[Dale]

reader@newsguy.com wrote:
> Configuring a new kernel is a dreaded task here.  It seems I walk
> through a bewildering array of stuff that when pressing F1 on them I
> get more bewildering information I barely understand a word of.
>
> < SNIP >
>
> Can someone steer me to a more `in depth' tutorial?  Or to something
> they've found to really throw some light the chore?  Not necessarily
> about iptables but just the general chore of configuring a kernel
> wisely. 
>
>   

The first time is the hardest one.  I did a make mrproper then ran make
menuconfig and just got started.  The third time the kernel booted up at
least.  The biggest thing is getting the file systems, drivers for your
drive controller and other critical things that are needed to boot up. 
After that, you can add them as needed. 

If you get a kernel that boots up fine and allows you to do things, save
it.  I almost always have a couple old kernels laying around /boot. 
That way if the current one gets corrupt or something, you can at least
fall back on a old one.  That may not help if /boot is corrupt but you
get the idea.  Here is my saved one and how I name them:

root@smoker / # ls -al /boot/bzImage-2.6.*
-rw-r--r-- 1 root root 2189488 2007-01-04 18:01
/boot/bzImage-2.6.18.gentoo-r6-1
-rw-r--r-- 1 root root 2357808 2007-06-08 05:47 /boot/bzImage-2.6.20-r8-1
-rw-r--r-- 1 root root 2389616 2007-06-08 07:01 /boot/bzImage-2.6.20-r8-2
-rw-r--r-- 1 root root 2396880 2007-06-13 01:53 /boot/bzImage-2.6.20-r8-3
-rw-r--r-- 1 root root 2417840 2007-08-31 23:10 /boot/bzImage-2.6.22-r5
-rw-r--r-- 1 root root 2421840 2007-11-25 13:26 /boot/bzImage-2.6.22-r9-1
-rw-r--r-- 1 root root 2437912 2007-12-18 04:25 /boot/bzImage-2.6.23-r3-1
root@smoker / #

The last number is the revision of that specific version.   You may
notice it takes even me a couple times to get it right. 

You may find that just like with the tutorials you have read, you are
going to be told different ways to do about everything.  Each of us have
our own ways of doing things based on past experiences.  Apply what
needs to be applied to your situation and keep it sane.

Hope this little bit of info helps.

Dale

:-)  :-)  :-) 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] A pared down kernel config

[Stroller]

On 5 Jan 2008, at 16:05, reader@newsguy.com wrote:

> Configuring a new kernel is a dreaded task here.  It seems I walk
> through a bewildering array of stuff that when pressing F1 on them I
> get more bewildering information I barely understand a word of.
>
> For 8 or 9 yrs now I've mostly skirted the issue by using  
> defaults.  ...

I'm not going to read all the details of all of the responses which  
have appeared here already, so here's my take.

1) The people who configure the kernel options for commercial distros  
are very experienced geeks.
2) I am unlikely to make sufficient performance savings by funroll- 
looping my own kernel to justify the time I'll spend doing so.

Now I periodically grab a copy of the latest knoppix CD I can find -  
I use these a lot, anyway - and take a copy the kernel .config from  
there. Chances are the kernel I want to compile on my Gentoo system  
is a little newer than the one from the Knoppix CD, so I run `make  
oldconfig` and add in most everythign as modules. I take a couple of  
minutes to look for my network card's driver in `make menuconfig` and  
compile it in statically. This results in a kernel config which  
surely supports all the hardware in my system. An awful lot of the  
drivers & also additional drivers that I don't need compiled as  
modules - perfect! If I need them they're loaded in dynamically at  
boot time, if not they don't consume any system resources.

Stroller.

-- 
gentoo-user@lists.gentoo.org mailing list