I'd say it's a VERY bad idea to build everything in ... you're gonna have tons of problems, I can guarantee it.

Could you please elaborate on that statement?

I just did that and though of course I didn't check everything be working, what I am using seems to work so far.

At least I feel safe as my laptop's fan is running ;)

The only driver I had to modularize afterwards was "nouveau" as else I couldn't see anything on the console while booting:
[EDIT]I just figured out why nouveau has to be modularized reading this post from Linus: otherwise the firmware for the graphics card will never be loaded.

But be there any inconvenience in doing that -- especially if that could put my system at risk -- of course I'd be pleased to know which.

Meanwhile I must admit that for my own use cases I can't see much benefit in having everything built-in -- just wanted to try, considering your statement as a challenge :cool:

[EDIT] Of course I did "make localmodconfig" then "make localyesconfig". So it's not "everything built in" but "the drivers I use built in". Otherwise there is the "allyesconfig" target but I wouldn't advise anybody to use it -- except may be kernel developers but I very much doubt they need my advises anyway...

Yeah I also ran into the USB thing since I hadn't plugged in any USB storage devices and like you said the modules weren't in use. I don't know if I would recommend this for first time kernel compilers but if you have some experience this is a great tool.

I'm already running 2.6.32, I may have to try stripping this one down and see what happens.

Wonder when they will include a RunLikeVersion Variable.

[ * ] Run Like Linux 2.6.17
[ ] Run Like Linux 2.6.21
[ ] Run Like Linux 2.6.26
[ ] Run Like Linux 2.6.31
[ ] Run Like Linux 2.6.32


Anybody notice the higher the version the more ram it eats?

:D

Well, the main problem is that you can't unload modules. So, this can cause problems if two modules are trying to use the same device, or if a module that you don't need tries to probe or probes excessively for a device that does not exist. Also, sometimes floppy drives malfunction if you build-in 'floppy', I've had this happen, had to build it as a module.

The only way to build everything in is if you only build-in modules that you know you will need. So, if you find a list of the modules that you know you need, you can safely build those in. But using "allyesconfig" just builds all modules in, which is crazy. Not sure why they put this as an option.

I agree. That's why I would recommend to those wanting to try (I suggest you start from an already modular running kernel which fits your needs) to do something like that:
zcat /proc/config.gz > .config
make localmodconfig
make menuconfig #to add what's missing
make localyesconfig
make menuconfig #to modularize what shouldn't be built-in

Also I suggest using "local version" option in "general setup" to differentiate between modules directories in /lib/modules

Anybody still using floppy drives around here? ;)

My guess (only a guess) is that it is used only by kernel or driver developers looking for conflicting drivers. I'd guess of something similar for "localnoconfig". But "localrandconfig" is clearly the funniest.

Well, I sometimes use floppies, but it's rare. Still, I expect the drive to work. I have a portable USB floppy.

Indeed, they might use it to prevent what I was talking about. I suppose, if they tested it well enough, they could eliminate any such issues.

Wow, this IS cool. Anything to move along the process of recompiling a custom kernel is great. :hatsoff: to the developers for this new feature.

Does this also mean it will make sure that framebuffer options is also compiled? Seeing how one of the most common mistakes with a recompiled kernel is the forgetting to compile that feature, resulting in a blank screen at boot up.

... VerRRRrry InterrrRRrrresting
 

It looks like some real progress on this front. Congrats and THANKS to the kernel team!!

Years ago, I managed mainframes and we installed the OS from source every time. We use a "monitor generator" utility to create a set of definitions (an assembler header file) and then used "make" leaving things to run overnight. [grin]

One mon-gen feature I'd like to see worked like this.

1. Dialogs asked us to name the hardware that we wanted to use.
2. The tool then examined the currently running hardware making a compare with items we said that we wanted or expected. If things did not match, the tool saved what it knew and reported hardware install and config details for whatever was missing: "power on or add this controller" "connect that device" "load a tape" ... whatever.
3. After we danced with the hardware, we restarted mon-gen. Step #2 repeated until we agreed that expectations were met.
4. All these expectations either enabled or disabled or modified which features were available for option configuration. For example, absent network parts, all net specific config options were no longer available.
[(grin) I said this was on mainframes a while ago (grin)]

This process worked in onion-layer fashion: really basic hardware,
memory, disks, the console, more complex hardware, terminals, networking, and so on. Software was also layered in similar ways.

I cannot tell you how many hours were saved when mon-gen told me "you said to expect this feature at item #1 but I never found enabling parts at step #2. Here are things to do to resolve that conflict: A, B, ..., Z"

It would be nice to have similar "expectations" added to kernel config. It would be wonderful to have "expectations" added to distro install as well.

Cheers,
~~~ 0;-Dan

BTW/ During distro install, it might be nice if we layered the onion rather than relied so much on shell globbing or similar package processing. Start with minimum packages to install a kernel and modules. Add daemons and utilities that enable a running system.
This point might be a minimum configuration "single user" install.
Follow with application support that is closest to the hardware.
Add layer on related layer until done where each layer is a bootable
system with some set of features. -- just a thought

try running "make old_confg" this will bring older config up to speed with the newer kernel
"make def_iax86-64"or "make def_iax86" I think will probe the computer and give you a bare bones run almost all hardware
kernel 64bit or 32bit you will still need to set up file systems and other options

"make def_iax86-64" and "make def_ix86" simply load the default configuration files found under arch/x86/config (IIRC the path).

Anybody still using floppy drives around here?
 

I actually have a pair of 8" elephants along with a single 5-1/4' and 3-1/2'
here in the shack

still lots of old data on them

john

I compile in my filesystems
 

And I think filesystems and drivers for your HD and optical drives should be compiled in kernel. I have never used a functional initrd after the initial install when testing a new Slackware version. I have used them later only for aesthetic purposes (splash screens).

Very nice.
 

Have just tried the localmodconfig operation.

With that, the time to make bzImage was reduced by about 1 minute. And make modules was reduced from 24 minutes to just over 4 minutes.

This is on a dual hyprethreaded 2.8Ghz Xeon box.

Nice savings in time. My thanks to the developers.