LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 12-10-2009, 09:00 AM   #16
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266

I'd say it's a VERY bad idea to build everything in ... you're gonna have tons of problems, I can guarantee it.
 
Old 12-10-2009, 03:38 PM   #17
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,641

Original Poster
Rep: Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827
Quote:
Originally Posted by H_TeXMeX_H View Post
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:
Code:
bash-3.1$ lsmod
Module                  Size  Used by
nouveau               670383  2 
bash-3.1$
[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

[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...

Last edited by Didier Spaier; 03-05-2010 at 05:30 PM.
 
Old 12-10-2009, 05:24 PM   #18
Daedra
Senior Member
 
Registered: Dec 2005
Location: Springfield, MO
Distribution: Slackware64-14.1
Posts: 1,215

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by ~sHyLoCk~ View Post
Ok I finally did it. Now with a customized 2.6.32 kernel. localmodconfig is quite useful but not that well implemented yet. I had inserted my USB drive before running localmodconfig, but at the end of the compilation process I was left without any USB support. I did a make clean and make menuconfig again to check out what happened and saw that "USB Mass storage support" was off and many USB options weren't auto-detected. My soundcard module wasnt picked up either. It's a generic Intel sound card. So I had to enable those modules and recompile kernel. Now everything works great. However this option did help me getting rid of a lot of unnecessary stuffs quite easily.
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.
 
Old 12-10-2009, 07:10 PM   #19
em21701
Member
 
Registered: Feb 2008
Location: Rhode Island, USA
Distribution: Slackware12.2 & Slackware64-13
Posts: 247

Rep: Reputation: 40
I'm already running 2.6.32, I may have to try stripping this one down and see what happens.
 
Old 12-10-2009, 10:10 PM   #20
salemboot
Member
 
Registered: Mar 2007
Location: America
Distribution: Linux
Posts: 158

Rep: Reputation: 36
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?

 
Old 12-11-2009, 03:34 AM   #21
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266
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.
 
Old 12-11-2009, 03:09 PM   #22
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware-14.0 on a Lenovo T61 6457-4XG
Posts: 3,641

Original Poster
Rep: Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827Reputation: 827
Quote:
Originally Posted by H_TeXMeX_H View Post
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.

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.
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

Quote:
Also, sometimes floppy drives malfunction if you build-in 'floppy', I've had this happen, had to build it as a module.
Anybody still using floppy drives around here?

Quote:
But using "allyesconfig" just builds all modules in, which is crazy. Not sure why they put this as an option.
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.

Last edited by Didier Spaier; 12-11-2009 at 03:16 PM.
 
Old 12-11-2009, 03:15 PM   #23
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266Reputation: 1266
Quote:
Originally Posted by Didier Spaier View Post

Anybody still using floppy drives around here?

My guess (only a guess) is it 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.
 
Old 12-11-2009, 03:32 PM   #24
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware 14.1 64-bit with multilib
Posts: 2,074

Rep: Reputation: 187Reputation: 187
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.

Quote:
1.8. Easy local kernel configuration

Most people uses the kernel shipped by distros - and that's good. But some people like to compile their own kernels from kernel.org, or maybe they like following the Linux development and want to try it. Configuring your own kernel, however, has become a very difficult and tedious task - there're too many options, and some times userspace software will stop working if you don't enable some key option. You can use a standard distro .config file, but it takes too many time to compile all the options it enables.

To make easier the process of configuration, a new build target has been added: make localmodconfig. It runs "lsmod" to find all the modules loaded on the current running system. It will read all the Makefiles to map which CONFIG enables a module. It will read the Kconfig files to find the dependencies and selects that may be needed to support a CONFIG. Finally, it reads the .config file and removes any module "=m" that is not needed to enable the currently loaded modules. With this tool, you can strip a distro .config of all the unuseful drivers that are not needed in our machine, and it will take much less time to build the kernel. There's an additional "make localyesconfig" target, in case you don't want to use modules and/or initrds.
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.
 
Old 12-11-2009, 05:15 PM   #25
SaintDanBert
Senior Member
 
Registered: Jan 2009
Location: Austin, TX
Distribution: Mint-15 with Cinnamon & KDE
Posts: 1,271
Blog Entries: 3

Rep: Reputation: 86
... 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
 
Old 12-11-2009, 07:52 PM   #26
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 776

Rep: Reputation: 88
Quote:
Originally Posted by swampdog2002 View Post
That is interesting news, and which will be very useful. On this note, I have always wondered if it was problematic with using a .config file from an earlier kernel release to use to build a new kernel from source. For example, if going from 2.6.29.6 to 2.6.32, if you load the .config from 2.6.29.6 into 2.6.32 when compiling, would problems result from this? The reason I ask is that I have done this before, and noticed when I loaded an older .config from an older kernel branch that there a few text exceptions thrown in the background, but couldn't quite make them out due to the kernel configuration menu being in the foreground. All seemed to build well with no errors in the process, so I don't know. Anyway, I'll be trying this new method in the future to see what results. Thanks for sharing this.
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
 
Old 12-12-2009, 02:17 AM   #27
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,724

Rep: Reputation: 449Reputation: 449Reputation: 449Reputation: 449Reputation: 449
"make def_iax86-64" and "make def_ix86" simply load the default configuration files found under arch/x86/config (IIRC the path).
 
Old 12-12-2009, 07:17 AM   #28
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.1 (3.14.0) UEFI enabled
Posts: 344

Rep: Reputation: 71
Smile 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
 
Old 12-12-2009, 10:08 AM   #29
folkenfanel
Member
 
Registered: Sep 2004
Location: formerly Fanelia and Zaibach
Distribution: Slackware-current with KDE 4.8.5
Posts: 299

Rep: Reputation: 35
Talking 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).
 
Old 12-22-2009, 05:12 AM   #30
guzzi
Member
 
Registered: Jun 2004
Location: Lawrence, KS
Distribution: Slackware
Posts: 294

Rep: Reputation: 32
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.
 
  


Reply

Tags
kernel


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what am I missing in my kernel configuration, kernel panic Kristian2 Slackware 16 10-05-2009 07:01 PM
Hosed my kernel - LUKS partition is not making it easier king111 Linux - General 1 11-23-2008 02:24 PM
[SOLVED] Diff between Kernel Compilation and Kernel Configuration ?? vikas027 Linux - Enterprise 8 09-20-2008 01:01 AM
New FAQ topic: Should I edit my kernel configuration?/Should I build a custom kernel? chort *BSD 10 09-10-2004 11:15 PM
Windows route configuration easier than Linux??? hdalle Linux - Networking 5 08-25-2004 06:14 AM


All times are GMT -5. The time now is 01:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration