Re: compiling 2.6

From: William D. Tallman (
Date: 03/18/04

Date: Wed, 17 Mar 2004 18:58:57 -0500

P.T. Breuer wrote:

> William D. Tallman <> wrote:
>> Timothy Murphy wrote:
>> > William D. Tallman wrote:
>> >
>> >> So what is the consensus on compiling the 2.6 kernel: cram it in the
>> >> kernel
>> >> or keep it as modules?
>> >
>> > I didn't understand this question.
>> > I don't see any difference re modules between 2.4.* and 2.6.*
>> There are functions said not to be compiled directly into the kernel, and
>> so not available as modules.
> This sentence makes no sense. If they are not compiled in the kernel
> then they are in modules. There is nowhere else!

ROFL!! Hello, Peter! Yep, makes no sense at all: the first 'not' was a
typo.. <sigh>
>> Obviously, I haven't read all the literature,
> There's nothing to read. What are you talking about?

I'm talking about all the literature that is applicable to the new kernel.
Now, you do know that such literature exists, don't you... <grin>
>> but thought I'd ask here to see if any differences have already been
>> noted.
> In what? There's no conceivable difference, and nobody knows what you
> are talking about!

No differences? Why a new minor number, then?
>> May I ask how extensive your experience with this new kernel might be?
> Mines a lot more than yours!

Warn't talkin' to you, Peter. Everyone knows that your experience in these
things is extensive. LOL!!!
>> > It doesn't seem to me any less "straightforward".
>> > The GUI interface to "make xconfig" is a lot nicer.
>> Ummm... well, I don't really like GUIs all that much, so I can't
>> comment.
> So use make config or make menuconfig or edit .config yourself.
> Peter

Well, actually I've gotten to the point with this kernel that I'm
editing .config, just to make sure that I'm seeing all the choices. I've
found that choices appear or disappear depending on other choices, and that
bothers me.

In any case, some functionality formerly available as modules is now said to
be compiled directly into the kernel. I gather that this means there is no
choice in the matter. Also, some stuff is deprecated in favor or new stuff
(like asla instead of oss; acpi instead of apm; etc). As I'm very slow of
wit, it'll take me some time to discover all this myself, so I thought I'd
ask here first.

Apparently no one here knows anything about this, so....

Bill Tallman

Registered Linux User: #221586
Mdk-10.0 and Slackware-9.1
A Luxuriance of Linux!!!

Relevant Pages

  • Re: Kernel: /dev/ram1 (rd.c) not releasing unused memory automatically any more?
    ... > Peter T. Breuer wrote: ... Easily - look at the kernel code. ... you can still do the allocation - send BLKFLSBUF while the device ... Note the absence of any protection. ...
  • RE: maximum memory capacity
    ... On Mon, 26 Jan 2004, Chiu, PCM (Peter) wrote: ... 64GB because the address extensions will prevent the kernel from booting ... The opteron's long mode supports 1TB of addressable memory the current ...
  • Re: 2 TB partition support
    ... >> Hello Peter, ... >> What is the maximum partition size for a patched 2.4.x kernel, ... >> where are those patches? ... The 2.4 kernel keeps the block device sizes in an unsigned int, ...
  • Re: [SLE] Kernel 2.6.5-7.104 bugs!
    ... On Thursday 19 August 2004 16:38, Peter B Van Campen wrote: ... Bad kernel, bad SuSE, please ... >> video burn worked flawlessly after that. ... > Hi Lee, ...
  • Re: Have virtual memory limits on linux changed since 1997?
    ... Peter T. Breuer wrote: ... from Red Hat Enterprise Linux if you need it (probably better have 8G RAM ... This gives each user process a 4G address space, ... Could the kernel use it for IO buffers or something? ...