Re: ISA hardware discovery -- the elegant solution

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Eric S. Raymond wrote:


> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial.  This would
> make the autoconfigurator much more capable.  Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.


Better: create a /proc/driver and every driver will register in it.
This file can help some bug report (and not only autoconfigurator).

BTW, my new tests for:
   memory (request_mem_region)
   io port (request_region)
   irq (request_irq)
   dma (request_dma)
are nearly completes.
I think every ISA card should registers one of
these resources.
With the check of register_blkdev, register_chrdev
and miscdevices we should have a complete list of the
old ISA devices.
(this would detect only already detected devices,
but autoconfigure is not yet designed for bootfloppies
makers).

With such new test: no patch to kernel and nearly automatic
generation of probes.

Some patch are still welcome. I.e.:
some people with copy+paste have not changes the driver
string. A kernel patch will help distinguish the two drivers.
watchdog: to many driver register as 'watchdog' (or 'serial',
or 'ps2mouse'. This will create some difficulties to
autoconfigurators. A patch will help us (but it would break
other userspace tools?)

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Giacomo Catenazzi <cate@debian.org>:
> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial.  This would
> > make the autoconfigurator much more capable.  Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
>  
> Better: create a /proc/driver and every driver will register in it.
> This file can help some bug report (and not only autoconfigurator).

That would be fine with me.  But wouldn't it involve adding a new
initialization-time call to every driver.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals...  It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
         -- Albert Gallatin, Oct 7 1789

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Eric S. Raymond wrote:

> Giacomo Catenazzi <cate@debian.org>:
> 
>>>With this change, generating a report on ISA hardware and other
>>>facilities configured in at boot time would be trivial.  This would
>>>make the autoconfigurator much more capable.  Best of all, the only
>>>change required to accomplish this would be safe edits of print format
>>>strings.
>>>
>> 
>>Better: create a /proc/driver and every driver will register in it.
>>This file can help some bug report (and not only autoconfigurator).
>>
> 
> That would be fine with me.  But wouldn't it involve adding a new
> initialization-time call to every driver.


I think we can add it automatically, modifing one of the
the modules macros. (this works automatically only for
trit symbols).
Hmm. IIRC there is a  big module/driver API (for modules) change
in 2.5 programs (driver registration,...). In this case we should
only modify the API before it will be effectivelly used, and
the changes will go automatically in kernel...

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Giacomo Catenazzi <cate@dplanet.ch>:
> >>Better: create a /proc/driver and every driver will register in it.
> >>This file can help some bug report (and not only autoconfigurator).
> > 
> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
> 
> I think we can add it automatically, modifing one of the
> the modules macros. (this works automatically only for
> trit symbols).

That would be OK.  I think there are *very* few drivers left that 
aren't modular.

> Hmm. IIRC there is a  big module/driver API (for modules) change
> in 2.5 programs (driver registration,...). In this case we should
> only modify the API before it will be effectivelly used, and
> the changes will go automatically in kernel...

This sounds encouraging.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Ideology, politics and journalism, which luxuriate in failure, are
impotent in the face of hope and joy.
	-- P. J. O'Rourke

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> That would be fine with me.  But wouldn't it involve adding a new
> initialization-time call to every driver.

man lsmod

Re: ISA hardware discovery -- the elegant solution

[Mr. James W. Laferriere]

	Hello All ,  And what mechanism is going to be used for an -all-
	compiled in kernel ?  Everyone and there brother is so enamoured
	of Modules .  Not everyone uses nor will use modules .
		Tia ,  JimL

On Mon, 14 Jan 2002, Alan Cox wrote:

> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
>
> man lsmod
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> 	Hello All ,  And what mechanism is going to be used for an -all-
> 	compiled in kernel ?  Everyone and there brother is so enamoured
> 	of Modules .  Not everyone uses nor will use modules .

For 2.5 if things go to plan there will be no such thing as a "compiled in"
driver. They simply are not needed with initramfs holding what were once the
"compiled in" modules.

Alan

Hardwired drivers are going away?

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> For 2.5 if things go to plan there will be no such thing as a "compiled in"
> driver. They simply are not needed with initramfs holding what were once the
> "compiled in" modules.

This is something of a bombshell.  Not necessarily a bad one, but...

Alan, do you have *any* *freakin'* *idea* how much more complicated
the CML2 deduction engine had to be because the basic logical entity
was a tristate rather than a bool?  If this plan goes through, I'm
going to be able to drop out at least 20% of the code, with most of
that 20% being in the nasty complicated bits where the maintainability
improvement will be greatest.  And I can get rid of the nasty "vitality"
flag, which probably the worst wart on the language.

Yowza...so how soon is this supposed to happen?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role.	-- Edward Abbey

Re: Hardwired drivers are going away?

[David Lang]

I can see a couple reasons for building a kernel without useing modules.

1. security, if you don't need any modules you can disable modules entirly
and then it's impossible to add a module without patching the kernel first
(the module load system calls aren't there)

2. speed, there was a discussion a few weeks ago pointing out that there
is some overhead for useing modules (far calls need to be used just in
case becouse the system can't know where the module will be located IIRC)

3. simplicity in building kernels for other machines. with a monolithic
kernel you have one file to move (and a bootloader to run) with modules
you have to move quite a few more files.

modules are good for distros and for machines that have to worry about
hotpluged equipment (but even that is less nessasary then it used to be)
but for servers that don't change their hardware they aren't nessasary,
why should they have to deal with them?

David Lang




On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Date: Mon, 14 Jan 2002 13:10:50 -0500
> From: Eric S. Raymond <esr@thyrsus.com>
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Mr. James W. Laferriere <babydr@baby-dragons.com>,
>      Giacomo Catenazzi <cate@debian.org>,
>      Linux Kernel List <linux-kernel@vger.kernel.org>
> Subject: Hardwired drivers are going away?
>
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
>
> This is something of a bombshell.  Not necessarily a bad one, but...
>
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool?  If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest.  And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
>
> Yowza...so how soon is this supposed to happen?
> --
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> Government should be weak, amateurish and ridiculous. At present, it
> fulfills only a third of the role.	-- Edward Abbey
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Hardwired drivers are going away?

[Alan Cox]

> 1. security, if you don't need any modules you can disable modules entirly
> and then it's impossible to add a module without patching the kernel first
> (the module load system calls aren't there)

Urban legend.

> 2. speed, there was a discussion a few weeks ago pointing out that there
> is some overhead for useing modules (far calls need to be used just in
> case becouse the system can't know where the module will be located IIRC)

I defy you to measure it on x86

> 3. simplicity in building kernels for other machines. with a monolithic
> kernel you have one file to move (and a bootloader to run) with modules
> you have to move quite a few more files.

tar or nfs mount; make modules_install.

Re: Hardwired drivers are going away?

[David Lang]

On Mon, 14 Jan 2002, Alan Cox wrote:

> > 1. security, if you don't need any modules you can disable modules entirly
> > and then it's impossible to add a module without patching the kernel first
> > (the module load system calls aren't there)
>
> Urban legend.
>

If this is the case then why do I get systemcall undefined error messages
when I make a mistake and attempt to load a module on a kernel without
modules enabled?

> > 2. speed, there was a discussion a few weeks ago pointing out that there
> > is some overhead for useing modules (far calls need to be used just in
> > case becouse the system can't know where the module will be located IIRC)
>
> I defy you to measure it on x86

during the discussion a few weeks ago there were people pointing out cases
where this overhead would be a problem.

> > 3. simplicity in building kernels for other machines. with a monolithic
> > kernel you have one file to move (and a bootloader to run) with modules
> > you have to move quite a few more files.
>
> tar or nfs mount; make modules_install.
>
not on my firewalls thank you.

David Lang

Re: Hardwired drivers are going away?

[Andrew Pimlott]

On Mon, Jan 14, 2002 at 10:57:19AM -0800, David Lang wrote:
> On Mon, 14 Jan 2002, Alan Cox wrote:
> 
> > > 1. security, if you don't need any modules you can disable modules entirly
> > > and then it's impossible to add a module without patching the kernel first
> > > (the module load system calls aren't there)
> >
> > Urban legend.
> 
> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?

It's an urban legend that this is a security benefit.  grep the
hacker zines for injecting code into a non-modular kernel.

> > > 2. speed, there was a discussion a few weeks ago pointing out that there
> > > is some overhead for useing modules (far calls need to be used just in
> > > case becouse the system can't know where the module will be located IIRC)
> >
> > I defy you to measure it on x86
                  ^^^^^^^^^^
> during the discussion a few weeks ago there were people pointing out cases
> where this overhead would be a problem.

Above.

> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.
> >
> > tar or nfs mount; make modules_install.
> >
> not on my firewalls thank you.

You won't install tar on your firewalls?  Weird :-)

Andrew

Re: Hardwired drivers are going away?

[Alan Cox]

> > Urban legend.
> 
> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?

Because you are using insmod. The guys who break into your computer probably 
are not in their own language "that lame".

> > I defy you to measure it on x86
> 
> during the discussion a few weeks ago there were people pointing out cases
> where this overhead would be a problem.

TLB miss overhead for kernel modules is very very hard to measure, at least
on the x86 platform. It can be an issue in userspace as you address much
larger objects and in certain cases like scanning an element in an array
of objects hit a TLB reload each scan or two (think about vertical line draw
unaccelerated in X11)

> > tar or nfs mount; make modules_install.
> >
> not on my firewalls thank you.

If you are that worried just burn a new root file system on CD when you 
upgrade your firewall. At least I hope if you are going to pretend to be 
so secure that tar is a bad idea you have no writable file store on the
machine ?

Alan

Re: Hardwired drivers are going away?

[Horst von Brand]

> On Mon, 14 Jan 2002, Alan Cox wrote:

> > > 1. security, if you don't need any modules you can disable modules
> > > entirly and then it's impossible to add a module without patching
> > > the kernel first (the module load system calls aren't there)

> > Urban legend.

> If this is the case then why do I get systemcall undefined error messages
> when I make a mistake and attempt to load a module on a kernel without
> modules enabled?

AFAIU the security improvement of no-modules are way overrated.

[...]

> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.

> > tar or nfs mount; make modules_install.

> not on my firewalls thank you.

You keep compilers and stuff on your firewalls then?!

I get them over via ssh or by floppy/CD. Same idea.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Hardwired drivers are going away?

[crispin]

On Tue, Jan 15, 2002 at 11:45:39AM +0100, Horst von Brand wrote:
> > On Mon, 14 Jan 2002, Alan Cox wrote:
> 
> > > > 1. security, if you don't need any modules you can disable modules
> > > > entirly and then it's impossible to add a module without patching
> > > > the kernel first (the module load system calls aren't there)
> 
> > > Urban legend.
> 
> > If this is the case then why do I get systemcall undefined error messages
> > when I make a mistake and attempt to load a module on a kernel without
> > modules enabled?
> 
> AFAIU the security improvement of no-modules are way overrated.

insmod knark.o

Crispin

Re: Hardwired drivers are going away?

[David Lang]

one other thing re: simplicity.

bootloaders

I know that many of you who are advocating this new approach despise lilo,
but for many people it does the job just fine. with the new approach when
switching between kernels you now not only need to switch the kernel
images, but also the initrd (or equivalent) images.

also don't forget that the current way of storing modules can have
problems when some kernel comile options change (SMP for example, but IIRC
there are others) if you make modules mandatory you will have to fix this
first.

David Lang


>
> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
>

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello Alan ,

On Mon, 14 Jan 2002, Alan Cox wrote:
> > 1. security, if you don't need any modules you can disable modules entirly
> > and then it's impossible to add a module without patching the kernel first
> > (the module load system calls aren't there)
>
> Urban legend.
	I do not agree .  Got proof ?  Yes that is a valid question .

> > 2. speed, there was a discussion a few weeks ago pointing out that there
> > is some overhead for useing modules (far calls need to be used just in
> > case becouse the system can't know where the module will be located IIRC)
> I defy you to measure it on x86
	OK ,How about sparc-64/alpha/ia64/... ?

> > 3. simplicity in building kernels for other machines. with a monolithic
> > kernel you have one file to move (and a bootloader to run) with modules
> > you have to move quite a few more files.
> tar or nfs mount; make modules_install.
	Please my laugh'o meter is stuck already .  Sorry .  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[Alan Cox]

> > Urban legend.
> 	I do not agree .  Got proof ?  Yes that is a valid question .

Most of the rootkit type stuff I see nowdays includes code for loading
patches into module free kernels. Its a real no win. The better ones support
regexp scanning so they can patch kernels where the sysadmin thinks he/she
is cool and has hidden or crapped in System.map

> > > case becouse the system can't know where the module will be located IIRC)
> > I defy you to measure it on x86
> 	OK ,How about sparc-64/alpha/ia64/... ?

Not generally found in your grandmothers PC

> > > 3. simplicity in building kernels for other machines. with a monolithic
> > > kernel you have one file to move (and a bootloader to run) with modules
> > > you have to move quite a few more files.
> > tar or nfs mount; make modules_install.
> 	Please my laugh'o meter is stuck already .  Sorry .  JimL

Then fix it, because the above works well. Also remember that autoconfig
tools won't be able to guess remote machines very well 8)

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello Alan ,

On Mon, 14 Jan 2002, Alan Cox wrote:
> > > Urban legend.
> > 	I do not agree .  Got proof ?  Yes that is a valid question .
> Most of the rootkit type stuff I see nowdays includes code for loading
> patches into module free kernels. Its a real no win. The better ones support
> regexp scanning so they can patch kernels where the sysadmin thinks he/she
> is cool and has hidden or crapped in System.map
	Same as I am seeing .  This does not eleviate the fact that
	modules can & are a still a security issue .  Yes , sloppy
	administration is still the biggest culprit in 'most' compromises .

> > > > case becouse the system can't know where the module will be located IIRC)
> > > I defy you to measure it on x86
> > 	OK ,How about sparc-64/alpha/ia64/... ?
> Not generally found in your grandmothers PC
	No,  But it is -mine- !  If I can not have complete control over
	my system due to the way the Fathers of this operating system
	are taking it I will have no choice but to use another or be stuck
	at a non-maintained version .  Now mind you I LIKE LINUX !

> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
> > > tar or nfs mount; make modules_install.
> > 	Please my laugh'o meter is stuck already .  Sorry .  JimL
> Then fix it, because the above works well. Also remember that autoconfig
> tools won't be able to guess remote machines very well 8)
	Show me , Please .  I am not convinced .  I shall try out the new
	level of kernel without a doubt .  But ,  I find the concept that
	-everything- is dynamic to be wrong .  Mind you My opinion .
		Twyl ,  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[Alan Cox]

> 	No,  But it is -mine- !  If I can not have complete control over
> 	my system due to the way the Fathers of this operating system
> 	are taking it I will have no choice but to use another or be stuck
> 	at a non-maintained version .  Now mind you I LIKE LINUX !

Right but you aren't going to go and use autoconfig except maybe to get
an initial Configuration to frob with ?

Alan

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello Alan ,

On Mon, 14 Jan 2002, Alan Cox wrote:
> > 	No,  But it is -mine- !  If I can not have complete control over
> > 	my system due to the way the Fathers of this operating system
> > 	are taking it I will have no choice but to use another or be stuck
> > 	at a non-maintained version .  Now mind you I LIKE LINUX !
> Right but you aren't going to go and use autoconfig except maybe to get
> an initial Configuration to frob with ?
	Ok , Now I am confused .  I guess it's not hard to do .
	Is the Kernel headed toward Soft drivers or not ?

	I get my initial Config (say from autoconf.) how will that keep
	the Drivers in the Kernel ?  Tia ,  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[David Lang]

On Mon, 14 Jan 2002, Alan Cox wrote:

> Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: babydr@baby-dragons.com
> Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
> > > Urban legend.
> > 	I do not agree .  Got proof ?  Yes that is a valid question .
>
> Most of the rootkit type stuff I see nowdays includes code for loading
> patches into module free kernels. Its a real no win. The better ones support
> regexp scanning so they can patch kernels where the sysadmin thinks he/she
> is cool and has hidden or crapped in System.map
>
> > > > case becouse the system can't know where the module will be located IIRC)
> > > I defy you to measure it on x86
> > 	OK ,How about sparc-64/alpha/ia64/... ?
>
> Not generally found in your grandmothers PC

doesn't matter, they are likly to be found on dedicated servers where
the flexibility of modules is not needed and the slight performance
advantage is desired.

making everything modular is fine for desktops/laptops but why should
dedicated servers pay the price?

> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
> > > tar or nfs mount; make modules_install.
> > 	Please my laugh'o meter is stuck already .  Sorry .  JimL
>
> Then fix it, because the above works well. Also remember that autoconfig
> tools won't be able to guess remote machines very well 8)

I don't want autoconfig to detect my remote machines I want to specify
them directly. (there are likly to be things on the motherboards of
machines that I don't want to compile into the kernel, sound cards for
servers are one example, video drivers are another, and USB is a third)

autoconfig is supposed to be an option, not the only way to compile a
kernel (or are you saying that you don't want to be able to use your 1.2G
athlon to build the kernel for your 486?)

David Lang

Re: Hardwired drivers are going away?

[Alexander Viro]

On Mon, 14 Jan 2002, David Lang wrote:

> doesn't matter, they are likly to be found on dedicated servers where
> the flexibility of modules is not needed and the slight performance
> advantage is desired.
> 
> making everything modular is fine for desktops/laptops but why should
> dedicated servers pay the price?

There should be no price.  And AFAICS that's doable.
 
> autoconfig is supposed to be an option, not the only way to compile a
> kernel (or are you saying that you don't want to be able to use your 1.2G
> athlon to build the kernel for your 486?)

autoconfig is completely separate story.  There are very good reasons to
avoid built-in/modular crap, regardless of the autoconf.  Every #ifdef MODULE
is a bug waiting to happen - simply because the stuff gets out of sync.
Every place that consists of
#ifdef CONFIG_FOO
	init_foo();
#endif
....
is a permanent source of PITA for out-of-tree drivers/patch merging/etc.
And that's aside of the fun with ordering, etc.

If we can get rid of performance hit on modular code - we should go
for that variant simply because it reduces the amount of bug sources.

Autoconfig and other details of ESR's Aunt Tillie fetish belong to
alt.sex.* - from time to time they may be amusing, but let's not
mix them with the technical arguments, OK?

Re: Hardwired drivers are going away?

[Chris Friesen]

Alexander Viro wrote:
> 
> On Mon, 14 Jan 2002, David Lang wrote:
> 
> > doesn't matter, they are likly to be found on dedicated servers where
> > the flexibility of modules is not needed and the slight performance
> > advantage is desired.
> >
> > making everything modular is fine for desktops/laptops but why should
> > dedicated servers pay the price?
> 
> There should be no price.  And AFAICS that's doable.

I haven't been following the initramfs stuff, but now I have a question. 
Currently we're using initrd to store a kernel and compressed ramdisk bundled
together as an ~7MB single file that gets netbooted by firmware in a card.  Will
it be possible to bundle initramfs together with the kernel into a single file
in this same manner?

Thanks,

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Hardwired drivers are going away?

[Alexander Viro]

On Mon, 14 Jan 2002, Chris Friesen wrote:

> I haven't been following the initramfs stuff, but now I have a question. 
> Currently we're using initrd to store a kernel and compressed ramdisk bundled
> together as an ~7MB single file that gets netbooted by firmware in a card.  Will
> it be possible to bundle initramfs together with the kernel into a single file
> in this same manner?

<shrug> kernel unpacks to rootfs after init_vfs_caches().  It does
	populate_root(archive_start, archive_size);
followed by releasing that area.  That's it.  If you have these variables
set - it will work, no matter how did the archive get there.

Re: Hardwired drivers are going away?

[Ian Molton]

On a sunny Mon, 14 Jan 2002 11:44:59 -0800 (PST) David Lang gathered a
sheaf of electrons and etched in their motions the following immortal
words:

> doesn't matter, they are likly to be found on dedicated servers where
> the flexibility of modules is not needed and the slight performance
> advantage is desired.

Exactly WHAT performance advantage? once the module is loaded, its loaded.
most modules use the same code to handle modular and non-modular builds
anyhow (look at the ide drivers, for example)

Re: Hardwired drivers are going away?

[David Lang]

the impact is in all calls to the module, if they are far calls instead of
near calls each and every call is (a hair) slower.

so the code can be the same and still be slower to get to.

you can argue that it's not enough slower to matter, but even Alan admits
there is some impact.

David Lang

On Mon, 14 Jan 2002, Ian Molton wrote:

> Date: Mon, 14 Jan 2002 20:51:24 +0000
> From: Ian Molton <spyro@armlinux.org>
> To: linux-kernel@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
> On a sunny Mon, 14 Jan 2002 11:44:59 -0800 (PST) David Lang gathered a
> sheaf of electrons and etched in their motions the following immortal
> words:
>
> > doesn't matter, they are likly to be found on dedicated servers where
> > the flexibility of modules is not needed and the slight performance
> > advantage is desired.
>
> Exactly WHAT performance advantage? once the module is loaded, its loaded.
> most modules use the same code to handle modular and non-modular builds
> anyhow (look at the ide drivers, for example)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Hardwired drivers are going away?

[Brian Gerst]

David Lang wrote:
> 
> the impact is in all calls to the module, if they are far calls instead of
> near calls each and every call is (a hair) slower.
> 
> so the code can be the same and still be slower to get to.
> 
> you can argue that it's not enough slower to matter, but even Alan admits
> there is some impact.
> 
> David Lang

Let's get the terminology right here (for x86 at least):
Far jump: Changes to a new code segment, absolute address
Near jump: Same code segment, 4-byte relative offset
Short jump: Same code segment, 1-byte signed offset

The kernel never uses far jumps except for some BIOS calls and during
booting.  The difference betwen near and short jumps is very minute. 
Short jumps are limited to +/- 128 bytes, so are really only applicable
for small loops.  All function calls between object files must be near
jumps, as the assembler does not not know the distance of an unresolved
symbol and must assume the largest possible offset.

--

				Brian Gerst

Re: Hardwired drivers are going away?

[David Lang]

my apologies for the terminology errors, I was trying to go from memory
from the thread here late last year.

David Lang

On Mon, 14 Jan 2002, Brian Gerst wrote:

> Date: Mon, 14 Jan 2002 18:12:43 -0500
> From: Brian Gerst <bgerst@didntduck.org>
> To: David Lang <dlang@diginsite.com>
> Cc: Ian Molton <spyro@armlinux.org>, linux-kernel@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
> David Lang wrote:
> >
> > the impact is in all calls to the module, if they are far calls instead of
> > near calls each and every call is (a hair) slower.
> >
> > so the code can be the same and still be slower to get to.
> >
> > you can argue that it's not enough slower to matter, but even Alan admits
> > there is some impact.
> >
> > David Lang
>
> Let's get the terminology right here (for x86 at least):
> Far jump: Changes to a new code segment, absolute address
> Near jump: Same code segment, 4-byte relative offset
> Short jump: Same code segment, 1-byte signed offset
>
> The kernel never uses far jumps except for some BIOS calls and during
> booting.  The difference betwen near and short jumps is very minute.
> Short jumps are limited to +/- 128 bytes, so are really only applicable
> for small loops.  All function calls between object files must be near
> jumps, as the assembler does not not know the distance of an unresolved
> symbol and must assume the largest possible offset.
>
> --
>
> 				Brian Gerst
>

Re: Hardwired drivers are going away?

[Ian Molton]

On a sunny Mon, 14 Jan 2002 14:11:48 -0800 (PST) David Lang gathered a
sheaf of electrons and etched in their motions the following immortal
words:

> the impact is in all calls to the module, if they are far calls instead
> of near calls each and every call is (a hair) slower.
> 
> so the code can be the same and still be slower to get to.
> 
> you can argue that it's not enough slower to matter, but even Alan admits
> there is some impact.

Ok, #1 please dont send me courtesy copies without indicating so.

#2 Not all architectures have a problem with 'far' or 'near' calls, and
frankly, I'm glad the kernels design isnt being crippled just to serve the
fundamentally CRAP x86 architecture, for once.

Re: Hardwired drivers are going away?

[H. Peter Anvin]

Followup to:  <20020114232247.195bf441.spyro@armlinux.org>
By author:    Ian Molton <spyro@armlinux.org>
In newsgroup: linux.dev.kernel
> 
> #2 Not all architectures have a problem with 'far' or 'near' calls, and
> frankly, I'm glad the kernels design isnt being crippled just to serve the
> fundamentally CRAP x86 architecture, for once.
> 

Especially since the x86 *ISN'T* one of the architectures with this
particular problem.  'far' and 'near' as used in this thread don't
refer to the x86 segmentation crud.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Hardwired drivers are going away?

[David Lang]

note: this discussion has moved away from autoconfig to requiring
everything to be modules.

autoconfig is a useful tool in some cases, but is not going to be used
everywhere.

I view modules as being in the same catagory.

David Lang


On Mon, 14 Jan 2002, Alan Cox wrote:

> Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: babydr@baby-dragons.com
> Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
> Subject: Re: Hardwired drivers are going away?
>
> > > Urban legend.
> > 	I do not agree .  Got proof ?  Yes that is a valid question .
>
> Most of the rootkit type stuff I see nowdays includes code for loading
> patches into module free kernels. Its a real no win. The better ones support
> regexp scanning so they can patch kernels where the sysadmin thinks he/she
> is cool and has hidden or crapped in System.map
>
> > > > case becouse the system can't know where the module will be located IIRC)
> > > I defy you to measure it on x86
> > 	OK ,How about sparc-64/alpha/ia64/... ?
>
> Not generally found in your grandmothers PC
>
> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
> > > tar or nfs mount; make modules_install.
> > 	Please my laugh'o meter is stuck already .  Sorry .  JimL
>
> Then fix it, because the above works well. Also remember that autoconfig
> tools won't be able to guess remote machines very well 8)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Hardwired drivers are going away?

[Aaron Lehmann]

On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote:
> Not generally found in your grandmothers PC

What kind of an argument is this?!? Linux developers used to care
about portability to and performance on non-x86 platforms.

Re: Hardwired drivers are going away?

[Alexander Viro]

On Tue, 15 Jan 2002, Aaron Lehmann wrote:

> On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote:
> > Not generally found in your grandmothers PC
> 
> What kind of an argument is this?!? Linux developers used to care
> about portability to and performance on non-x86 platforms.

<rant>

Guys, could you lay off whatever the fuck you are smoking?  And
I mean everybody involved.

*	autoconfig is part of ESR's wet dream.  Ignore him and he'll go away.
*	Aunt Tillie and her magical mistery whorehouse <<--->>
*	performance problems with modules are real, need to be solved and
	can be solved.
*	disabling module loading doesn't buy any security.
*	it's easy to make irrevertible disabling modules _after_ boot.
*	initramfs is independent from modules
*	it is _not_ initrd or an analog
*	it doesn't involve a shitload of extra files
*	it removes tons of crap from kernel
*	it allows to simplify build process and get rid of quite a few sources
	of bugs, _if_ performance problems with modules are solved

Now could we fscking drop these threads?  Or at least take care to separate
myths from reality before posting more crap.

</rant>

Re: Hardwired drivers are going away?

[Alan Cox]

> On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote:
> > Not generally found in your grandmothers PC
> 
> What kind of an argument is this?!? Linux developers used to care
> about portability to and performance on non-x86 platforms.

Read the entire thread (I know thats like asking you to read war and peace)
but if you've not read it in context you will misunderstand arguments (as
you do above).

Re: Hardwired drivers are going away?

[Florian Weimer]

"Mr. James W. Laferriere" <babydr@baby-dragons.com> writes:

> 	Hello Alan ,
>
> On Mon, 14 Jan 2002, Alan Cox wrote:
>> > 1. security, if you don't need any modules you can disable modules entirly
>> > and then it's impossible to add a module without patching the kernel first
>> > (the module load system calls aren't there)
>>
>> Urban legend.
> 	I do not agree .  Got proof ?  Yes that is a valid question .

http://www.phrack.org/phrack/58/p58-0x07

Globally preloading a shared library in user space is almost as
effective, BTW, unless your critical binaries are linked statically
(which is unusual on most systems nowadays).

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello Florian ,

On Fri, 18 Jan 2002, Florian Weimer wrote:
> "Mr. James W. Laferriere" <babydr@baby-dragons.com> writes:
> > 	Hello Alan ,
> > On Mon, 14 Jan 2002, Alan Cox wrote:
> >> > 1. security, if you don't need any modules you can disable modules entirly
> >> > and then it's impossible to add a module without patching the kernel first
> >> > (the module load system calls aren't there)
> >> Urban legend.
> > 	I do not agree .  Got proof ?  Yes that is a valid question .
> http://www.phrack.org/phrack/58/p58-0x07
	Thank you for the pointer .  Fine you do not need to allow modules
	in order for a hacker to insert their code .  It is still another
	thing to allow modules & not put & use signatures on them .  AFAIK
	Linux doesn't have a method to load encrypted & signed modules at
	this time .  Please ,  someone prove me wrong .  I -personally-
	like statically compiled kernels .  The method being pushed forth
	at present doesn't allow that ,  Unless I am completely mistaken
	about what Alan & the rest have been discussing .  Again PLEASE
	someone prove me wrong about this also .

> Globally preloading a shared library in user space is almost as
> effective, BTW, unless your critical binaries are linked statically
> (which is unusual on most systems nowadays).
	I can beleive that 8-} .  Statically or written to readonly media
 	or the drive hard set to readonly ;-) .  I have followed most of
	Alan's suggestions security concerns over the years & a few that
	I thought of along the way .  Which later I found had been being
	done alot longer than I would have thought .  Tia ,  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[Keith Owens]

On Fri, 18 Jan 2002 17:20:02 -0500 (EST), 
"Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
>	Linux doesn't have a method to load encrypted & signed modules at
>	this time .

And never will.  Who loads the module - root.  Who maintains the list
of signatures - root.  Who controls the code that verifies the
signature - root.

Your task Jim, should you choose to accept it, is to make the kernel
distinguish between a good use of root and a malicious use by some who
has broken in and got root privileges.  When you can do that, then we
can add signed modules.

Re: Hardwired drivers are going away?

[Frank van de Pol]

On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote:
> On Fri, 18 Jan 2002 17:20:02 -0500 (EST), 
> "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
> >	Linux doesn't have a method to load encrypted & signed modules at
> >	this time .
> 
> And never will.  Who loads the module - root.  Who maintains the list
> of signatures - root.  Who controls the code that verifies the
> signature - root.
> 
> Your task Jim, should you choose to accept it, is to make the kernel
> distinguish between a good use of root and a malicious use by some who
> has broken in and got root privileges.  When you can do that, then we
> can add signed modules.
> 

If you want to secure your box, why don't you simply put a lock on it and
throw away the key? Really, what might help the paranoid admins in this case
is a setting in the kernel which basically disables the ability to load or
unload modules. Of course once set this setting can not been turned with
rebooting the box.

Frank.


-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

Re: Hardwired drivers are going away?

[Bruce Harada]

On Mon, 21 Jan 2002 00:20:41 +0100
Frank van de Pol <fvdpol@home.nl> wrote:

> If you want to secure your box, why don't you simply put a lock on it and
> throw away the key? Really, what might help the paranoid admins in this case
> is a setting in the kernel which basically disables the ability to load or
> unload modules. Of course once set this setting can not been turned with
> rebooting the box.

...and how would you guarantee that this setting remains set, in the face of
some nasty little cracker screwing around with /dev/kmem?

Re: Hardwired drivers are going away?

[Andreas Ferber]

On Mon, Jan 21, 2002 at 09:54:58AM +0900, Bruce Harada wrote:
> 
> ...and how would you guarantee that this setting remains set, in the face of
> some nasty little cracker screwing around with /dev/kmem?

If the attacker gained the ability to play with /dev/kmem, he can
already load modules into the kernel, regardless if the kernel is
actually compiled with module support or not. You can find various
papers describing how to do it via google, and AFAIK some rootkits are
already using those techniques, so it's even "scriptkiddy-ready".

Face it, there is absolutely /no/ security gain in disabling module
support.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: Hardwired drivers are going away?

[Bruce Harada]

On Mon, 21 Jan 2002 04:49:52 +0100
Andreas Ferber <aferber@techfak.uni-bielefeld.de> wrote:

> On Mon, Jan 21, 2002 at 09:54:58AM +0900, Bruce Harada wrote:
> > 
> > ...and how would you guarantee that this setting remains set, in the face
> > of some nasty little cracker screwing around with /dev/kmem?
> 
> If the attacker gained the ability to play with /dev/kmem, he can
> already load modules into the kernel, regardless if the kernel is
> actually compiled with module support or not. You can find various
> papers describing how to do it via google, and AFAIK some rootkits are
> already using those techniques, so it's even "scriptkiddy-ready".

Er... that was exactly what I meant - perhaps you meant to reply to the parent
post?

Re: Hardwired drivers are going away?

[Andreas Ferber]

On Mon, Jan 21, 2002 at 01:45:16PM +0900, Bruce Harada wrote:
> 
> Er... that was exactly what I meant - perhaps you meant to reply to the parent
> post?

Hmm, I understood your post as if you consider a simple flag disabling
module loading a step-back regarding security. I stand corrected.

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: Hardwired drivers are going away?

[Anton Altaparmakov]

At 23:20 20/01/02, Frank van de Pol wrote:

>On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote:
> > On Fri, 18 Jan 2002 17:20:02 -0500 (EST),
> > "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
> > >     Linux doesn't have a method to load encrypted & signed modules at
> > >     this time .
> >
> > And never will.  Who loads the module - root.  Who maintains the list
> > of signatures - root.  Who controls the code that verifies the
> > signature - root.
> >
> > Your task Jim, should you choose to accept it, is to make the kernel
> > distinguish between a good use of root and a malicious use by some who
> > has broken in and got root privileges.  When you can do that, then we
> > can add signed modules.
>
>If you want to secure your box, why don't you simply put a lock on it and
>throw away the key? Really, what might help the paranoid admins in this case
>is a setting in the kernel which basically disables the ability to load or
>unload modules. Of course once set this setting can not been turned with
>rebooting the box.

Er that sounds like just disabling modules in the kernel altogether (kernel 
compile option exists for this since the beginning of time)... I do that on 
all servers I control. Not only for security reasons but also because I 
suspect it produces smaller and probably faster kernels (I haven't tested 
this in any way, just a guess).

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello Anton ,

On Mon, 21 Jan 2002, Anton Altaparmakov wrote:
> At 23:20 20/01/02, Frank van de Pol wrote:
> >On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote:
> > > On Fri, 18 Jan 2002 17:20:02 -0500 (EST),
> > > "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
> > > >     Linux doesn't have a method to load encrypted & signed modules at
> > > >     this time .
> > > And never will.  Who loads the module - root.  Who maintains the list
> > > of signatures - root.  Who controls the code that verifies the
> > > signature - root.
> > > Your task Jim, should you choose to accept it, is to make the kernel
> > > distinguish between a good use of root and a malicious use by some who
> > > has broken in and got root privileges.  When you can do that, then we
> > > can add signed modules.
> >If you want to secure your box, why don't you simply put a lock on it and
> >throw away the key? Really, what might help the paranoid admins in this case
> >is a setting in the kernel which basically disables the ability to load or
> >unload modules. Of course once set this setting can not been turned with
> >rebooting the box.

> Er that sounds like just disabling modules in the kernel altogether (kernel
> compile option exists for this since the beginning of time)... I do that on
> all servers I control. Not only for security reasons but also because I
> suspect it produces smaller and probably faster kernels (I haven't tested
> this in any way, just a guess).
	This is just what the Heads are trying to do away with .  There
	will only be module enabled kernels .  JimL

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[Andrew Morton]

"Mr. James W. Laferriere" wrote:
> 
>         This is just what the Heads are trying to do away with .  There
>         will only be module enabled kernels .  JimL

I suspect none of these "Heads" spend much time in protracted
email debug sessions.  Because the *first* thing you do is
ask the tester to compile the relevant driver into the
kernel.

The problems which the removal of this option will cause include:

1: Inability to look up symbols in the kernel elf image.
2: Breaks the kernel profiler
3: breaks kgdb
4: breaks ksymoops.

How often have we seen nonsensical backtraces here because
modules were involved?   Possibly we can include a table
of module base addresses in the Oops output and teach ksymoops
about it.

This proposal is, frankly, brain-damaged.  It will significantly
impeded kernel developers in remote problem diagnosis and it will
weaken the kernel development toolchain.

There's a lot of work to be done to overcome this damage, and
given the difficulty of getting debug tools into the mainstream
kernel, the damage may well be permanent.

-

Re: Hardwired drivers are going away?

[Keith Owens]

On Sun, 20 Jan 2002 17:30:12 -0800, 
Andrew Morton <akpm@zip.com.au> wrote:
>I suspect none of these "Heads" spend much time in protracted
>email debug sessions.  Because the *first* thing you do is
>ask the tester to compile the relevant driver into the
>kernel.
>
>The problems which the removal of this option will cause include:
>
>1: Inability to look up symbols in the kernel elf image.
>2: Breaks the kernel profiler
>3: breaks kgdb
>4: breaks ksymoops.
>
>How often have we seen nonsensical backtraces here because
>modules were involved?   Possibly we can include a table
>of module base addresses in the Oops output and teach ksymoops
>about it.

You see nonsensical backtraces because people persist in using the oops
decode option of klogd which is broken when faced with modules.  Turn
off klogd oops (klogd -x) and you get a raw backtrace which ksymoops
can handle.  Guess why these entries are in /proc/ksyms?

c48a2300 __insmod_3c589_cs_S.bss_L4	[3c589_cs]
c48a0000 __insmod_3c589_cs_O/lib/modules/2.4.17-xfs/kernel/drivers/net/pcmcia/3c589_cs.o_M3C332CFF_V132113	[3c589_cs]
c48a22a0 __insmod_3c589_cs_S.data_L96	[3c589_cs]
c48a1820 __insmod_3c589_cs_S.rodata_L1152	[3c589_cs]
c48a0060 __insmod_3c589_cs_S.text_L6064	[3c589_cs]

ksymoops uses the __insmod entries to work out exactly where each
module is, it gives an accurate backtrace with modules.  man insmod for
details.

Kernel debuggers like kgdb and kdb use kallsyms which has full support
for modules.  kgdb can also use the __insmod entries in /proc/ksyms to
tell gdb where each module was loaded.

ksymoops has a save map option (-s) which writes out the combined
system map, including the kernel and all symbols from all modules.

Sure, a dynamic system requires a little more work, but it has all been
done.  Just kill the broken klogd code so it stops corrupting log data.

Re: Hardwired drivers are going away?

[Andrew Morton]

Keith Owens wrote:
> 
> On Sun, 20 Jan 2002 17:30:12 -0800,
> Andrew Morton <akpm@zip.com.au> wrote:
> >I suspect none of these "Heads" spend much time in protracted
> >email debug sessions.  Because the *first* thing you do is
> >ask the tester to compile the relevant driver into the
> >kernel.
> >
> >The problems which the removal of this option will cause include:
> >
> >1: Inability to look up symbols in the kernel elf image.
> >2: Breaks the kernel profiler
> >3: breaks kgdb
> >4: breaks ksymoops.
> >
> >How often have we seen nonsensical backtraces here because
> >modules were involved?   Possibly we can include a table
> >of module base addresses in the Oops output and teach ksymoops
> >about it.
> 
> You see nonsensical backtraces because people persist in using the oops
> decode option of klogd which is broken when faced with modules.  Turn
> off klogd oops (klogd -x) and you get a raw backtrace which ksymoops
> can handle.

ksymoops doesn't know what modules were loaded at the time
of the crash, and it doesn't know where they were loaded.

The `klogd -x' problem has been with us for *years* and
distributors still persist in turning it on.


>  Guess why these entries are in /proc/ksyms?
> 
> c48a2300 __insmod_3c589_cs_S.bss_L4     [3c589_cs]
> c48a0000 __insmod_3c589_cs_O/lib/modules/2.4.17-xfs/kernel/drivers/net/pcmcia/3c589_cs.o_M3C332CFF_V132113      [3c589_cs]
> c48a22a0 __insmod_3c589_cs_S.data_L96   [3c589_cs]
> c48a1820 __insmod_3c589_cs_S.rodata_L1152       [3c589_cs]
> c48a0060 __insmod_3c589_cs_S.text_L6064 [3c589_cs]
> 
> ksymoops uses the __insmod entries to work out exactly where each
> module is, it gives an accurate backtrace with modules.  man insmod for
> details.

It assumes too much.  Arjan has a kksymoops thingy which does the symbol
resolution at crash-time.  This seems much more reliable to me.  It also
handles the common case where the running vmlinux/System.map/etc no longer
exist.

> Kernel debuggers like kgdb and kdb use kallsyms which has full support
> for modules.  kgdb can also use the __insmod entries in /proc/ksyms to
> tell gdb where each module was loaded.
> 
> ksymoops has a save map option (-s) which writes out the combined
> system map, including the kernel and all symbols from all modules.
> 
> Sure, a dynamic system requires a little more work, but it has all been
> done.  Just kill the broken klogd code so it stops corrupting log data.

Keith, I have spent a *lot* of time working weird kernel bugs
with people via email.  Usually, things peter out simply because
the other party lacks the expertise or time to keep on doing
things.  So the bug doesn't get fixed.

I would prefer that all this become easier, simpler and more reliable.
We need a damn good reason for deprecating statically linked kernels
and certainly none has been presented yet.

-

Re: Hardwired drivers are going away?

[Keith Owens]

On Sun, 20 Jan 2002 18:04:00 -0800, 
Andrew Morton <akpm@zip.com.au> wrote:
>ksymoops doesn't know what modules were loaded at the time
>of the crash, and it doesn't know where they were loaded.

/var/log/ksymoops.  man insmod and look for ksymoops assistance.

>The `klogd -x' problem has been with us for *years* and
>distributors still persist in turning it on.

Tell me about it :(.

>It assumes too much.  Arjan has a kksymoops thingy which does the symbol
>resolution at crash-time.

It can only get symbols that are in /proc/ksyms, i.e. the exported
symbols.  Proper crash analysis needs the full symbol table.

>It also
>handles the common case where the running vmlinux/System.map/etc no longer
>exist.

So does ksymoops, with reduced detail because it only has exported
symbols.

>I would prefer that all this become easier, simpler and more reliable.
>We need a damn good reason for deprecating statically linked kernels
>and certainly none has been presented yet.

That is a different problem.  Saying that modular kernels cause
problems for debugging is not a good enough reason to deprecate modular
kernels, all the problems have been solved.

Re: Hardwired drivers are going away?

[Andrew Morton]

Keith Owens wrote:
> 
> On Sun, 20 Jan 2002 18:04:00 -0800,
> Andrew Morton <akpm@zip.com.au> wrote:
> >ksymoops doesn't know what modules were loaded at the time
> >of the crash, and it doesn't know where they were loaded.
> 
> /var/log/ksymoops.  man insmod and look for ksymoops assistance.

Oh I have, extensively, when trying to get kgdb to play with
modules.  I did what any sensible person would do: gave up and went
for a static link.

I'm not aware of anyone getting kgdb working fully with modules.

> >The `klogd -x' problem has been with us for *years* and
> >distributors still persist in turning it on.
> 
> Tell me about it :(.
> 
> >It assumes too much.  Arjan has a kksymoops thingy which does the symbol
> >resolution at crash-time.
> 
> It can only get symbols that are in /proc/ksyms, i.e. the exported
> symbols.  Proper crash analysis needs the full symbol table.

Proper crash analysis needs to know the load address of each module
at the time of the crash.  We should print them out at Oops time.

> >It also
> >handles the common case where the running vmlinux/System.map/etc no longer
> >exist.
> 
> So does ksymoops, with reduced detail because it only has exported
> symbols.
> 
> >I would prefer that all this become easier, simpler and more reliable.
> >We need a damn good reason for deprecating statically linked kernels
> >and certainly none has been presented yet.
> 
> That is a different problem.  Saying that modular kernels cause
> problems for debugging is not a good enough reason to deprecate modular
> kernels, all the problems have been solved.

They are patently *not* solved, because we continue to get a
stream of partially and competely useless oops reports.  It
is my empirical observation that this problem is worse when
modules are involved.  It is my personal experience that
modular code is harder to debug.

It is also my personal experience that the refusal of sbp2.o to
work correctly when statically linked was a complete pain in the
ass when trying to diagnose its deadlock and module refcount
problems.  It was only when I worked out that I could link it
statically and then get it to play via rescan-scsi-bus.sh that
I was able to make reasonably-paced progress in finding the bugs.

We don't want this to happen to every damn driver in the kernel.

-

Re: Hardwired drivers are going away?

[Keith Owens]

On Sun, 20 Jan 2002 18:56:34 -0800, 
Andrew Morton <akpm@zip.com.au> wrote:
>I'm not aware of anyone getting kgdb working fully with modules.

kgdb has a script that tells gdb where each module is loaded.  AFAIK it
uses add-symbol-file FILENAME -sSECTION ADDRESS, the __insmod entries
contain enough data to tell gdb what is going on.

>Proper crash analysis needs to know the load address of each module
>at the time of the crash.  We should print them out at Oops time.

You need 13 bits of data per module.  Where each of text, rodata, data
and bss sections were loaded, you cannot assume they are contiguous.
The length of those four sections.  Where the module is on disk, you
cannot assume the object name is the same as the module name, insmod
-o.  The timestamp and kernel version of the module when it was loaded,
to detect updates after the event.  All of that is encoded in the
__insmod entries in /proc/ksyms, 5 lines per module.

>> That is a different problem.  Saying that modular kernels cause
>> problems for debugging is not a good enough reason to deprecate modular
>> kernels, all the problems have been solved.
>
>They are patently *not* solved, because we continue to get a
>stream of partially and competely useless oops reports.

Rule 1.  Users do not read documentation.
Rule 2.  You can't do anything about rule 1.

If you want complete bug reports, write a script that forces the user
to submit all the required data.  Why do I feel the "Linux should have
a bug reporting system" thread starting again?

Re: Hardwired drivers are going away?

[Andrew Morton]

Keith Owens wrote:
> 
> On Sun, 20 Jan 2002 18:56:34 -0800,
> Andrew Morton <akpm@zip.com.au> wrote:
> >I'm not aware of anyone getting kgdb working fully with modules.
> 
> kgdb has a script that tells gdb where each module is loaded.  AFAIK it
> uses add-symbol-file FILENAME -sSECTION ADDRESS, the __insmod entries
> contain enough data to tell gdb what is going on.
> 
> >Proper crash analysis needs to know the load address of each module
> >at the time of the crash.  We should print them out at Oops time.
> 
> You need 13 bits of data per module.  Where each of text, rodata, data
> and bss sections were loaded, you cannot assume they are contiguous.
> The length of those four sections.  Where the module is on disk, you
> cannot assume the object name is the same as the module name, insmod
> -o.  The timestamp and kernel version of the module when it was loaded,
> to detect updates after the event.  All of that is encoded in the
> __insmod entries in /proc/ksyms, 5 lines per module.

That sounds OK.  Just print it first.  If it hits the logs then
great.  If it just scrolls off the screen then no loss.

> >> That is a different problem.  Saying that modular kernels cause
> >> problems for debugging is not a good enough reason to deprecate modular
> >> kernels, all the problems have been solved.
> >
> >They are patently *not* solved, because we continue to get a
> >stream of partially and competely useless oops reports.
> 
> Rule 1.  Users do not read documentation.
> Rule 2.  You can't do anything about rule 1.

Often the users know nothing about elf internals, kernel tools
and build processes and all of that.  They just want to get their
box back up and reliable, and they consider that any work they do 
in problem disgnosis is a favour for the developers (and I have no
problem with that attitude).

Often, we only get one shot at it.
 
> If you want complete bug reports, write a script that forces the user
> to submit all the required data.

It's in our interest to make it as easy as possible for the reporter.
Cut-and-paste is easy, so we should err on the side of overkill when
choosing which data to dump out.

> Why do I feel the "Linux should have
> a bug reporting system" thread starting again?

Yeah, let's not do that.  (But I'd be on the "no" side :-))

-

Re: Hardwired drivers are going away?

[yodaiken]

On Mon, Jan 21, 2002 at 01:25:18PM +1100, Keith Owens wrote:
> >I would prefer that all this become easier, simpler and more reliable.
> >We need a damn good reason for deprecating statically linked kernels
> >and certainly none has been presented yet.
> 
> That is a different problem.  Saying that modular kernels cause
> problems for debugging is not a good enough reason to deprecate modular
> kernels, all the problems have been solved.


Interesting definition of "solved".

Re: Hardwired drivers are going away?

[Kai Henningsen]

yodaiken@fsmlabs.com  wrote on 20.01.02 in <20020120204413.B6096@hq.fsmlabs.com>:

> On Mon, Jan 21, 2002 at 01:25:18PM +1100, Keith Owens wrote:
> > >I would prefer that all this become easier, simpler and more reliable.
> > >We need a damn good reason for deprecating statically linked kernels
> > >and certainly none has been presented yet.
> >
> > That is a different problem.  Saying that modular kernels cause
> > problems for debugging is not a good enough reason to deprecate modular
> > kernels, all the problems have been solved.
>
>
> Interesting definition of "solved".

Make that "all problems except the one of how to get everybody to use the  
correct solution", and it is the standard definition of "solved".

I.e., everything's solved except the marketing.

MfG Kai

Re: Hardwired drivers are going away?

[John Levon]

On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote:

> >How often have we seen nonsensical backtraces here because
> >modules were involved?   Possibly we can include a table
> >of module base addresses in the Oops output and teach ksymoops
> >about it.
> 
> You see nonsensical backtraces because people persist in using the oops
> decode option of klogd which is broken when faced with modules.  Turn
> off klogd oops (klogd -x) and you get a raw backtrace which ksymoops
> can handle.  Guess why these entries are in /proc/ksyms?
> 
> c48a2300 __insmod_3c589_cs_S.bss_L4	[3c589_cs]

and quite often the user has unloaded / loaded modules in the meantime
and the oops is useless.

It would be nice if klogd's oops detection just passed everything to ksymoops
untouched, and stored everything somewhere using -m

I don't see any reason why the internal profiler can't have an extended EIP
range to catch module samples either. Perhaps I'm missing something. Perhaps
no one cares enough ...

regards
john

-- 
"I hope you will find the courage to keep on living 
 despite the existence of this feature."
	- Richard Stallman

Re: Hardwired drivers are going away?

[Keith Owens]

On Mon, 21 Jan 2002 02:13:55 +0000, 
John Levon <movement@marcelothewonderpenguin.com> wrote:
>On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote:
>> Guess why these entries are in /proc/ksyms?
>> 
>> c48a2300 __insmod_3c589_cs_S.bss_L4	[3c589_cs]
>
>and quite often the user has unloaded / loaded modules in the meantime
>and the oops is useless.

/var/log/ksymoops.  I added the code and documented it nicely, man
insmod or ksymoops.  It's not my fault if nobody reads the docs!

>It would be nice if klogd's oops detection just passed everything to ksymoops
>untouched, and stored everything somewhere using -m

It would be better if klogd got out of the way completely.  Everything
is stored, just created /var/log/ksymoops.

>I don't see any reason why the internal profiler can't have an extended EIP
>range to catch module samples either. Perhaps I'm missing something. Perhaps
>no one cares enough ...

IMNSHO the profiler should use kallsyms.  Then it gets every symbol
from the kernel and from all modules, instead of only being able to
report on exported symbols.

int kallsyms_address_to_symbol(
        unsigned long     address,      /* Address to lookup */
        const char      **mod_name,     /* Set to module name */
        unsigned long    *mod_start,    /* Set to start address of module */
        unsigned long    *mod_end,      /* Set to end address of module */
        const char      **sec_name,     /* Set to section name */
        unsigned long    *sec_start,    /* Set to start address of section */
        unsigned long    *sec_end,      /* Set to end address of section */
        const char      **sym_name,     /* Set to full symbol name */
        unsigned long    *sym_start,    /* Set to start address of symbol */
        unsigned long    *sym_end       /* Set to end address of symbol */
        )

We have the technology.

Re: Hardwired drivers are going away?

[Thomas Zimmerman]

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

On 21-Jan 01:31, Keith Owens wrote:
> On Mon, 21 Jan 2002 02:13:55 +0000, 
> John Levon <movement@marcelothewonderpenguin.com> wrote:
> >On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote:
> >> Guess why these entries are in /proc/ksyms?
> >> 
> >> c48a2300 __insmod_3c589_cs_S.bss_L4	[3c589_cs]
> >
> >and quite often the user has unloaded / loaded modules in the meantime
> >and the oops is useless.
> 
> /var/log/ksymoops.  I added the code and documented it nicely, man
> insmod or ksymoops.  It's not my fault if nobody reads the docs!
> 
> >It would be nice if klogd's oops detection just passed everything to ksymoops
> >untouched, and stored everything somewhere using -m
> 
> It would be better if klogd got out of the way completely.  Everything
> is stored, just created /var/log/ksymoops.

Isn't part of the problem with klogd mangling is that is sort of works?
Change the format so that klogd doesn't touch it and that gets _wrong_ Oops
reports out of the way. [you do great work, now make someone else do some
too!] 

Just my $0.02, from a thankful user.

Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Hardwired drivers are going away?

[Horst von Brand]

Andrew Morton <akpm@zip.com.au> said:
> "Mr. James W. Laferriere" wrote:
> >         This is just what the Heads are trying to do away with .  There
> >         will only be module enabled kernels .  JimL

> I suspect none of these "Heads" spend much time in protracted
> email debug sessions.  Because the *first* thing you do is
> ask the tester to compile the relevant driver into the
> kernel.
> 
> The problems which the removal of this option will cause include:
> 
> 1: Inability to look up symbols in the kernel elf image.

ksymoops(8) is able to find them...

> 2: Breaks the kernel profiler

Which one?

> 3: breaks kgdb

Officially not wanted by the heads, so irrelevant

> 4: breaks ksymoops.

How so?
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Hardwired drivers are going away?

[John Levon]

On Mon, Jan 21, 2002 at 10:34:07AM +0100, Horst von Brand wrote:

> > 2: Breaks the kernel profiler
> 
> Which one?

readprofile(3) - the histogram only extends across the .text of the monolithic
kernel image

regards
john

-- 
"I hope you will find the courage to keep on living 
 despite the existence of this feature."
	- Richard Stallman

Re: Hardwired drivers are going away?

[Anton Altaparmakov]

At 01:07 21/01/02, Mr. James W. Laferriere wrote:
>On Mon, 21 Jan 2002, Anton Altaparmakov wrote:
> > At 23:20 20/01/02, Frank van de Pol wrote:
> > >On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote:
> > > > On Fri, 18 Jan 2002 17:20:02 -0500 (EST),
> > > > "Mr. James W. Laferriere" <babydr@baby-dragons.com> wrote:
> > > > >     Linux doesn't have a method to load encrypted & signed modules at
> > > > >     this time .
> > > > And never will.  Who loads the module - root.  Who maintains the list
> > > > of signatures - root.  Who controls the code that verifies the
> > > > signature - root.
> > > > Your task Jim, should you choose to accept it, is to make the kernel
> > > > distinguish between a good use of root and a malicious use by some who
> > > > has broken in and got root privileges.  When you can do that, then we
> > > > can add signed modules.
> > >If you want to secure your box, why don't you simply put a lock on it and
> > >throw away the key? Really, what might help the paranoid admins in 
> this case
> > >is a setting in the kernel which basically disables the ability to load or
> > >unload modules. Of course once set this setting can not been turned with
> > >rebooting the box.
>
> > Er that sounds like just disabling modules in the kernel altogether (kernel
> > compile option exists for this since the beginning of time)... I do that on
> > all servers I control. Not only for security reasons but also because I
> > suspect it produces smaller and probably faster kernels (I haven't tested
> > this in any way, just a guess).
>         This is just what the Heads are trying to do away with .  There
>         will only be module enabled kernels .  JimL

Ah! Serves me right for jumping into a thread without reading the previous 
posts... I better shut up as I have no idea why this is being done. From my 
unknowledgeable point of view it seems daft but there probably are good 
reasons... I suppose even non-modular kernels can be modified by the root 
user to be exploited, it's just a little bit harder...

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Hardwired drivers are going away?

[Alexander Viro]

On Mon, 14 Jan 2002, David Lang wrote:

> I can see a couple reasons for building a kernel without useing modules.
> 
> 1. security, if you don't need any modules you can disable modules entirly
> and then it's impossible to add a module without patching the kernel first
> (the module load system calls aren't there)

Oh, please...  Give me permissions sufficient to make these syscalls
and in a couple of minutes your kernel will be replaced with ELIZA.
As a bonus - ELIZA running under TOPS-10 on PDP-10 emulator.  And talking
to PARRY.

Anyway, it's trivial to disable said system calls just before doing
execve("/sbin/init",...).  It won't buy you any security, but if you
insist...

> 2. speed, there was a discussion a few weeks ago pointing out that there
> is some overhead for useing modules (far calls need to be used just in
> case becouse the system can't know where the module will be located IIRC)

_That_ has to be addressed - regardless of anything else, if that suckitude
can be fixed it should be.

> 3. simplicity in building kernels for other machines. with a monolithic
> kernel you have one file to move (and a bootloader to run) with modules
> you have to move quite a few more files.

FVO"quite a few" equal to 2.  Kernel and initramfs.cpio.gz

Re: Hardwired drivers are going away?

[Aaron Lehmann]

On Mon, Jan 14, 2002 at 10:50:20AM -0800, David Lang wrote:
> I can see a couple reasons for building a kernel without useing modules.

I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain
bad. It will require an initrd (initramfs, or whatever), and force
kernel installation to be more difficult. The performance overhead
sounds like a major downside, epsecially when currently people know
what hardware they have and build things into the kernel accordingly.

Between this and CML2, my mental image of 2.5+ is starting to look
very grim.

Re: Hardwired drivers are going away?

[David Lang]

CML2 is a tradeoff in the kernel config process. it (currently) trades
time for correctness. It has no effect after you have built the kernel.

I like this becouse there have been several times where I have had to go
on a scavanger hunt to figure out what option I need to turn on before I
can turn on another option (something that CML2 will fix)

as for the kbuild 2.5 performance 'penalty', is it really slower then
always doign make dep; make clean; make bzImage? Yes I know I don't always
have to do that, but I don't understand the rules as to when I do and when
I don't (they sound simple at first but there keep being exceptions
raised). having the new kernel build process always get this right is
valuble.

also the time penalties associated with these two options is something
that can (and will) be dealt with over time as they get optimized and
rewritten to be faster.

these are VERY different from the modules thing which is permanently
introducing additional penalties into the system that can affect it for
as long as it's running.

David Lang


 On Tue, 15 Jan 2002, Aaron Lehmann wrote:

> On Mon, Jan 14, 2002 at 10:50:20AM -0800, David Lang wrote:
> > I can see a couple reasons for building a kernel without useing modules.
>
> I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain
> bad. It will require an initrd (initramfs, or whatever), and force
> kernel installation to be more difficult. The performance overhead
> sounds like a major downside, epsecially when currently people know
> what hardware they have and build things into the kernel accordingly.
>
> Between this and CML2, my mental image of 2.5+ is starting to look
> very grim.
>

Re: Hardwired drivers are going away?

[Aaron Lehmann]

On Tue, Jan 15, 2002 at 10:17:29AM -0800, David Lang wrote:
> CML2 is a tradeoff in the kernel config process. it (currently) trades
> time for correctness. It has no effect after you have built the kernel.

My gripe is more that I find it ugly. I'm very used to the menuconfig
appearance, and I do not appreciate the interface change.

And (we've been through this before) I am *NOT* going to install yet
another language runtime just to configure a kernel.

Re: Hardwired drivers are going away?

[Kai Henningsen]

aaronl@vitelus.com (Aaron Lehmann)  wrote on 15.01.02 in <20020115172413.GD7030@vitelus.com>:

> I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain
> bad. It will require an initrd (initramfs, or whatever), and force
> kernel installation to be more difficult. The performance overhead
> sounds like a major downside, epsecially when currently people know
> what hardware they have and build things into the kernel accordingly.

Installation more difficult? Significant performance overhead?

What *are* you smoking?

MfG Kai

Re: Hardwired drivers are going away?

[Mr. James W. Laferriere]

	Hello All ,  And on that day linux will loose one small person .
		Taf ,  JimL

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
>
> This is something of a bombshell.  Not necessarily a bad one, but...
>
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool?  If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest.  And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
>
> Yowza...so how soon is this supposed to happen?
> --
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> Government should be weak, amateurish and ridiculous. At present, it
> fulfills only a third of the role.	-- Edward Abbey
>

       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Hardwired drivers are going away?

[Alan Cox]

> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest.  And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
> 
> Yowza...so how soon is this supposed to happen?

Subject to availability. No contract implied or etc.. Its something to
tackle after the rest of initramfs works. Even if not then the lsmod case
can be made to work since its just a matter of putting the names in a segment
for the linker to collate.

We already have module_init/module_exit which is a big chunk of the cleanup.

Re: Hardwired drivers are going away?

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Yowza...so how soon is [the end of hard-compiled drivers] supposed to 
> > happen?
> 
> Subject to availability. No contract implied or etc.. Its something to
> tackle after the rest of initramfs works.

Dang.  This will make the CML2 inference engine work better in some
funky corner cases, too.  And its behavior will be easier to
understand all around.

Sign me up.  This will be a good change; I like it when I can make things
better by taking features *out* of my code.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
        -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.

Re: Hardwired drivers are going away?

[Alexander Viro]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
> 
> This is something of a bombshell.  Not necessarily a bad one, but...
> 
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool?  If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest.  And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
> 
> Yowza...so how soon is this supposed to happen?

Two technical obstacles:
	a) on some architecures modular code is slower (IIRC, the problem is
with medium-range calls being faster than far ones and usable only in the
kernel proper).  We probaly want to leave a gap after the .text and remap
.text of module in there - if I understand the problem that should be
enough, but that's really a question to folks dealing with these ports (PPC64
and Itanic?)
	b) current differences between options parsing in case of built-in
and modular drivers.

The rest is trivial and should be done in 2.5.4-pre* or so.

But it still leaves you with tristate - instead of yes/module/no it's
yes/yes, but don't put it on initramfs/no.  However, dependencies become
simpler - all you need is "I want this, that and that on initramfs" and
the rest can be found by depmod (i.e. configurator doesn't have to deal
with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
(== can't be M)").

Re: Hardwired drivers are going away?

[Rob Landley]

On Monday 14 January 2002 02:09 pm, Alexander Viro wrote:

> But it still leaves you with tristate - instead of yes/module/no it's
> yes/yes, but don't put it on initramfs/no.  However, dependencies become
> simpler - all you need is "I want this, that and that on initramfs" and
> the rest can be found by depmod (i.e. configurator doesn't have to deal
> with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> (== can't be M)").

This is something I've wondered about and would like to ask for clarification 
on: the relationship between the initramfs image and the kernel, build 
process-wise.

How much of the build process for the initramfs will be integrated with the 
kernel build?  Since the kernel won't boot without a matching initramfs, I 
take it that some kind of initramfs will be a kernel build target now?

There's been a lot of talk about having the source for a mini-libc (uclibc, 
dietlibc, some combo) in the kernel tree, and other people saying we should 
just grab the binary for build purposes.  The most obvious model I can think 
of for klibc staying seperate from the kernel is the user-space 
pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel.

The klibc source/binary debate still seems to be ongoing, but apart from 
that, will the build process for initramfs be part of the kernel build or not?

Rob.

Re: Hardwired drivers are going away?

[Greg KH]

On Mon, Jan 14, 2002 at 09:19:01AM -0500, Rob Landley wrote:
> 
> The klibc source/binary debate still seems to be ongoing, but apart from 
> that, will the build process for initramfs be part of the kernel build or not?

I would vote for yes.  I would like this, if for no other reason than
the number of kernel builds most kernel developers do :)

I was going to wait until kbuild 2.5 went into the tree before looking
at what would be needed to add this to the build process.

thanks,

greg k-h

Re: Hardwired drivers are going away?

[Keith Owens]

On Mon, 14 Jan 2002 09:19:01 -0500, 
Rob Landley <landley@trommello.org> wrote:
>How much of the build process for the initramfs will be integrated with the 
>kernel build?  Since the kernel won't boot without a matching initramfs, I 
>take it that some kind of initramfs will be a kernel build target now?
>
>There's been a lot of talk about having the source for a mini-libc (uclibc, 
>dietlibc, some combo) in the kernel tree, and other people saying we should 
>just grab the binary for build purposes.  The most obvious model I can think 
>of for klibc staying seperate from the kernel is the user-space 
>pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel.
>
>The klibc source/binary debate still seems to be ongoing, but apart from 
>that, will the build process for initramfs be part of the kernel build or not?

I am in two minds about this (but I am at one with my duality).  Part
of me says that users will want to tweak the initramfs process and they
may want to use different versions of klibc, so klibc and building
initramfs should be outside the kernel build.  Another part says that
users have to build initramfs before doing the install so initramfs and
klibc should be part of kbuild.

It will probably end up with klibc as part of the kernel tarball
supported by kbuild.  Generating initramfs will be done by a script,
kbuild will supply a sample but users can copy and change the sample to
suit their own requirements.

Re: Hardwired drivers are going away?

[Oliver Xymoron]

On Tue, 15 Jan 2002, Keith Owens wrote:

> On Mon, 14 Jan 2002 09:19:01 -0500,
> Rob Landley <landley@trommello.org> wrote:
> >How much of the build process for the initramfs will be integrated with the
> >kernel build?  Since the kernel won't boot without a matching initramfs, I
> >take it that some kind of initramfs will be a kernel build target now?
> >
> >There's been a lot of talk about having the source for a mini-libc (uclibc,
> >dietlibc, some combo) in the kernel tree, and other people saying we should
> >just grab the binary for build purposes.  The most obvious model I can think
> >of for klibc staying seperate from the kernel is the user-space
> >pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel.
> >
> >The klibc source/binary debate still seems to be ongoing, but apart from
> >that, will the build process for initramfs be part of the kernel build or not?
>
> I am in two minds about this (but I am at one with my duality).  Part
> of me says that users will want to tweak the initramfs process and they
> may want to use different versions of klibc, so klibc and building
> initramfs should be outside the kernel build.  Another part says that
> users have to build initramfs before doing the install so initramfs and
> klibc should be part of kbuild.
>
> It will probably end up with klibc as part of the kernel tarball
> supported by kbuild.  Generating initramfs will be done by a script,
> kbuild will supply a sample but users can copy and change the sample to
> suit their own requirements.

Better yet, we should do away with all install targets beyond assembling
the bootable images and provide sample install scripts in /scripts. Most
of it is already at odds with the distro's install and the remainder
becomes a maintenance issue with initramfs. Distro folks are going to be
working on initramfs-libc for their boot disks anyway and will undoubted
want to tweak such stuff greatly. Let's include Viro's
minimal-userspace-boot.c in scripts along with a
build-minimal-initramfs.sh and leave it at that.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Hardwired drivers are going away?

[Alan Cox]

> 	a) on some architecures modular code is slower (IIRC, the problem is
> with medium-range calls being faster than far ones and usable only in the
> kernel proper).  We probaly want to leave a gap after the .text and remap

Also with TLB mapping sizes (4Mb versus 4K)

> .text of module in there - if I understand the problem that should be
> enough, but that's really a question to folks dealing with these ports (PPC64
> and Itanic?)

For x86 you just need to leave a nice chunk of physical memory that is there
to copy the module text/data into as you insmod them during boot then give
the rest of the pool back to the paging system. This also solves the problem
with "can't be a module because I need 1Mb of linear space" drivers.

Alan

Re: Hardwired drivers are going away?

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> But it still leaves you with tristate - instead of yes/module/no it's
> yes/yes, but don't put it on initramfs/no.  However, dependencies become
> simpler - all you need is "I want this, that and that on initramfs" and
> the rest can be found by depmod (i.e. configurator doesn't have to deal
> with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> (== can't be M)").

Actually I think we may no longer be in tristate-land.  Instead, some
devices have the property "This belongs in initramfs if it's configured
at all" -- specifically, drivers for potential boot devices.  Everything
else can dynamic-load after boot time.  

In CML2 you can assign a symbol properties, which are written into
trailing comments in the config file on the same line as the symbol
value assignment.  One such property, "PRIVATE", is already
interpreted by the postprocessor that generates autoconf.h from the
configuration output; it prevents the symbol from being written to
autoconf.h.

The critical-for-boot property could be interpreted by the same
postprocessor script and turned into a manifest for initramfs.  There
would be no need for the inference engine or configurator to know
about this property at all, just as it doesn't need to know anything
about PRIVATE.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"To disarm the people... was the best and most effectual way to enslave them."
        -- George Mason, speech of June 14, 1788

Re: Hardwired drivers are going away?

[Rob Landley]

On Monday 14 January 2002 03:17 pm, Eric S. Raymond wrote:
> Alexander Viro <viro@math.psu.edu>:
> > But it still leaves you with tristate - instead of yes/module/no it's
> > yes/yes, but don't put it on initramfs/no.  However, dependencies become
> > simpler - all you need is "I want this, that and that on initramfs" and
> > the rest can be found by depmod (i.e. configurator doesn't have to deal
> > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> > (== can't be M)").
>
> Actually I think we may no longer be in tristate-land.  Instead, some
> devices have the property "This belongs in initramfs if it's configured
> at all" -- specifically, drivers for potential boot devices.  Everything
> else can dynamic-load after boot time.

No.  Just about every block device there is is a POTENTIAL root device.  Boot 
and root devices are seperate things (just as boot and root partitions are 
seperate things.)  Your kernel can decompress from an enternet boot prom if 
you're clever enough about.  You could theoretically have your root device on 
a USB storage device.  Booting from CD-ROM is fairly common, yet not 
something you normally want your installed kernel to have compiled in.

I've even seen kernels that load via tftp, including an initial ram disk, and 
either never have local storage of any kind or use it purely as swap space.  
(Why?  Really really really easy system administration of multiple terminals 
in libraries and kiosks and such.  It breaks, you drop in a new one (don't 
even have to image it).  No local hard drive liminates the #1 cause of system 
failure.  And there's no way an end-user can screw up its configuration in a 
way a reboot won't fix.)

What's interesting is what devices the root partition IS going to live on and 
this has NOTHING to do with the device itself.  It can be any device any 
normal partition lives on.  You can have IDE and SCSI in the same system.  
You can have hard drives, CD-ROM drives, and floppies.  The fact you can boot 
off of an IDE cd-rom doesn't mean you will, or that's how you want to 
configure your kernel.

When manually configuring, you select this.  And if the autoprober isn't 
smart enough to figure out what your root device is, it needs to be fixed.

Rob

Re: Hardwired drivers are going away?

[David Lang]

some systems don't want modules to be loaded after boot (yes it's security
that can be bypassed, but as long as it's not your only security it's
still worth doing)

also with hardwired drivers going away does this mean that other things
that are currently compiled in will become modules, like say the IP stack?

David Lang

 On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Date: Mon, 14 Jan 2002 15:17:48 -0500
> From: Eric S. Raymond <esr@thyrsus.com>
> To: Alexander Viro <viro@math.psu.edu>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
>      Mr. James W. Laferriere <babydr@baby-dragons.com>,
>      Giacomo Catenazzi <cate@debian.org>,
>      Linux Kernel List <linux-kernel@vger.kernel.org>
> Subject: Re: Hardwired drivers are going away?
>
> Alexander Viro <viro@math.psu.edu>:
> > But it still leaves you with tristate - instead of yes/module/no it's
> > yes/yes, but don't put it on initramfs/no.  However, dependencies become
> > simpler - all you need is "I want this, that and that on initramfs" and
> > the rest can be found by depmod (i.e. configurator doesn't have to deal
> > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> > (== can't be M)").
>
> Actually I think we may no longer be in tristate-land.  Instead, some
> devices have the property "This belongs in initramfs if it's configured
> at all" -- specifically, drivers for potential boot devices.  Everything
> else can dynamic-load after boot time.
>
> In CML2 you can assign a symbol properties, which are written into
> trailing comments in the config file on the same line as the symbol
> value assignment.  One such property, "PRIVATE", is already
> interpreted by the postprocessor that generates autoconf.h from the
> configuration output; it prevents the symbol from being written to
> autoconf.h.
>
> The critical-for-boot property could be interpreted by the same
> postprocessor script and turned into a manifest for initramfs.  There
> would be no need for the inference engine or configurator to know
> about this property at all, just as it doesn't need to know anything
> about PRIVATE.
> --
> 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> "To disarm the people... was the best and most effectual way to enslave them."
>         -- George Mason, speech of June 14, 1788
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Hardwired drivers are going away?

[Oliver Xymoron]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Alexander Viro <viro@math.psu.edu>:
> > But it still leaves you with tristate - instead of yes/module/no it's
> > yes/yes, but don't put it on initramfs/no.  However, dependencies become
> > simpler - all you need is "I want this, that and that on initramfs" and
> > the rest can be found by depmod (i.e. configurator doesn't have to deal
> > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there
> > (== can't be M)").
>
> Actually I think we may no longer be in tristate-land.  Instead, some
> devices have the property "This belongs in initramfs if it's configured
> at all" -- specifically, drivers for potential boot devices.  Everything
> else can dynamic-load after boot time.

The knowledge of what's required to boot can and should be moved out of
the kernel to distro land. 'make install' should call the distro's install
script that sez /boot and /lib are on ext3 on /dev/sd?, ergo I need to
include the ext3 and relevant SCSI modules.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Hardwired drivers are going away?

[Horst von Brand]

"Eric S. Raymond" <esr@thyrsus.com> said:

[...]

> Actually I think we may no longer be in tristate-land.  Instead, some
> devices have the property "This belongs in initramfs if it's configured
> at all" -- specifically, drivers for potential boot devices.  Everything
> else can dynamic-load after boot time.  

Then all SCSI drivers end up in the initramfs for the install kernel for
a distro? There might be _many_ devices configured that don't need to
reside on the initramfs.

OTOH, the initramfs will get built and populated by separate tools (just
like initrd is done today), so the alternatives would boil down to M/N.
_If_ the grand scheme of getting rid of builtins flies. I for one wouldn't
hold my breath.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: Hardwired drivers are going away?

[Eric S. Raymond]

Horst von Brand <brand@jupiter.cs.uni-dortmund.de>:
> > Actually I think we may no longer be in tristate-land.  Instead, some
> > devices have the property "This belongs in initramfs if it's configured
> > at all" -- specifically, drivers for potential boot devices.  Everything
> > else can dynamic-load after boot time.  
> 
> Then all SCSI drivers end up in the initramfs for the install kernel for
> a distro? There might be _many_ devices configured that don't need to
> reside on the initramfs.

No worries.  I have working code for a better approach now.  It turns
out not to be that hard to discover the root device, controller, and bus.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The end move in politics is always to pick up a gun.
	-- R. Buckminster Fuller

Re: Hardwired drivers are going away?

[Rusty Russell]

On Mon, 14 Jan 2002 14:09:16 -0500 (EST)
Alexander Viro <viro@math.psu.edu> wrote:
> Two technical obstacles:
> 	a) on some architecures modular code is slower (IIRC, the problem is
> with medium-range calls being faster than far ones and usable only in the
> kernel proper).  We probaly want to leave a gap after the .text and remap
> .text of module in there - if I understand the problem that should be
> enough, but that's really a question to folks dealing with these ports (PPC64
> and Itanic?)

Sparc64 has a special allocator.  PPC32 is not so lucky, and if the module
doesn't end up under 32MB we use trampolines (PLT in the ppc parlance).
PPC64 has similar issues.

> 	b) current differences between options parsing in case of built-in
> and modular drivers.

I have a patch for this, of course, but it's tied to my replacement module
loader:

	http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/param.patch.bz2

Cheers!
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: Hardwired drivers are going away?

[Dr. Kelsey Hudson]

This bothers me. I prefer building a monolithic kernel with only a few 
drivers compiled as modules (e.g. those drivers which are under active 
development and are upgraded often). I believe firmly that certain drivers 
should be part of the monolithic kernel.... either way, i'm not about to 
debate it. i'd just like to know exactly why this is being done, and to 
lodge an objection against it.

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > For 2.5 if things go to plan there will be no such thing as a "compiled in"
> > driver. They simply are not needed with initramfs holding what were once the
> > "compiled in" modules.
> 
> This is something of a bombshell.  Not necessarily a bad one, but...
> 
> Alan, do you have *any* *freakin'* *idea* how much more complicated
> the CML2 deduction engine had to be because the basic logical entity
> was a tristate rather than a bool?  If this plan goes through, I'm
> going to be able to drop out at least 20% of the code, with most of
> that 20% being in the nasty complicated bits where the maintainability
> improvement will be greatest.  And I can get rid of the nasty "vitality"
> flag, which probably the worst wart on the language.
> 
> Yowza...so how soon is this supposed to happen?
> 

-- 
 Kelsey Hudson                                           khudson@ctica.com 
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------     

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > That would be fine with me.  But wouldn't it involve adding a new
> > initialization-time call to every driver.
> 
> man lsmod

I couldn't make any sense at all out of this until your later posting
saying that compiled-in drivers are going away when initramfs comes in.
You might try being a *little* less terse...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Love your country, but never trust its government.
	-- Robert A. Heinlein.

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> I couldn't make any sense at all out of this until your later posting
> saying that compiled-in drivers are going away when initramfs comes in.
> You might try being a *little* less terse...

why ? 8)

(and yes that was meant to be a joke)

Alan

Re: ISA hardware discovery -- the elegant solution

[Stephen Shirley]

Hi,
	If, as Alan described, you can depend on the distro's installation
	program to have automatically identified all the hardware possible,
	and for the user to have specified and additional (i.e. isa etc) 
	devices, then could not the autoconfigurator simply see what drivers 
	are currently in use (via /proc/devices etc), check
	/etc/modules.conf for any that don't happen to be loaded at the
	time, and use that info to configure the new kernel. Unless there is
	some new piece of hardware that the new kernel supports that is
	present (and isn't supported by the old one), if linux was installed
	properly, you now have all the info you need, no? This removes the
	need for the configurator to do any sort of probing, neither are
	root proviledges required. Anyway, that's all probably blatantly
	obvious etc, so I'll just be quiet now.

Steve
-- 
"My mom had Windows at work and it hurt her eyes real bad"

RE: ISA hardware discovery -- the elegant solution

[Michael Lazarou (ETL)]

> -----Original Message-----
> From: Giacomo Catenazzi [mailto:cate@debian.org]
> >>
> >>The kernel's device drivers have, of course, to include probe
> >>routines, and those hard-compiled in typically log the presence of
> >>their hardware to /var/log/mesg when it loads.  By scanning that
> >>file, we in effect get to use those probes.
> >>
> > 
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> 
> Not a problem. Autoconfiguration is made to help configuring
> the kernel, before to compile it. So you need a linux working
> machine (actually you can cross-compile).
> 
> Our task is to allow user to compile a kernel, with the
> needed drivers, without the non used drivers.

OK, well I guess I am a little confused.

If I hit an autoconfigurator button then I would expect a kernel that
will boot and know everything there is to know about my machine.

Without probing the hardware how will the autoconfigurator cope with 
the hardware changing underneath it?

Michael

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Michael Lazarou (ETL) wrote:


>>Not a problem. Autoconfiguration is made to help configuring
>>the kernel, before to compile it. So you need a linux working
>>machine (actually you can cross-compile).
>>
>>Our task is to allow user to compile a kernel, with the
>>needed drivers, without the non used drivers.
>>
> 
> OK, well I guess I am a little confused.
> 
> If I hit an autoconfigurator button then I would expect a kernel that
> will boot and know everything there is to know about my machine.


Actually there is no yet 'autoconfigurator button'.
I recommend to run a std configuration tool and to check
the configuration before the kernel build phase.

> Without probing the hardware how will the autoconfigurator cope with 
> the hardware changing underneath it?


We probe the hardware (but in a soft manner).
Better: we probe nothing, we ask kernel to give us the results
of already done kernel probes. Thus we never hang, we never crash
machine, no 10-15 reboots to install a new kernel.
The good news: this is nearly enought.

Linux is magic: it can do infinite loops in 5 sec, but also
it can configure automatically a new kernel without real hardware
probes!.

	giacomo

Re: ISA hardware discovery -- the elegant solution

[Giacomo Catenazzi]

Michael Lazarou (ETL) wrote:

>>
>>The kernel's device drivers have, of course, to include probe
>>routines, and those hard-compiled in typically log the presence of
>>their hardware to /var/log/mesg when it loads.  By scanning that
>>file, we in effect get to use those probes.
>>
> 
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?


Not a problem. Autoconfiguration is made to help configuring
the kernel, before to compile it. So you need a linux working
machine (actually you can cross-compile).

Our task is to allow user to compile a kernel, with the
needed drivers, without the non used drivers.

If you want a good running kernel image:
   check the kernels in your distribution.
If you want to compile a general running kernel:
   use the kernel sources in your distribution (
   with your distribution's .config), or compile
   the std kernel with your distribution's .config

If you want a working kernel to boot Linux in your

   old/new/non-x86 machine: check the installation
   note of your distribution. Use special kernel (from
   your distribution,...)

 

You see: different task needs different tools.
Maybe we can merge some problems, but how? why?

[I still have a working version of autoconfigure in
shell, if some "boot-floppies" people need some
of our detection.]

But for old ISA cards (and some newer laptop) there is
only one method to find the right *kernel*:
boot and try (and changing kernels, parameters,...)
[check: installation document and internet resources].

We don't want a boot and retry for our configuration,
so let use the (incomplete) infos from kernel.

	giacomo

RE: ISA hardware discovery -- the elegant solution

[Michael Lazarou (ETL)]

> -----Original Message-----
> From: Eric S. Raymond [mailto:esr@thyrsus.com]
> Subject: ISA hardware discovery -- the elegant solution
> 
> 
> I've been thinking about the hardware-discovery problem for 
> ISA devices,
> and there may be an elegant solution.  It will take a number 
> of small changes
> to the kernel sources, however.
> 
> The kernel's device drivers have, of course, to include probe
> routines, and those hard-compiled in typically log the presence of
> their hardware to /var/log/mesg when it loads.  By scanning that
> file, we in effect get to use those probes.

Doesn't this mean that you would need a fully functional kernel
before you get to run the autoconfigurator?

Michael

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> Doesn't this mean that you would need a fully functional kernel
> before you get to run the autoconfigurator?

Yes, but this was always true.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the great struggle
for independence.	-- Attributed to Charles Austin Beard (1874-1948)

Re: ISA hardware discovery -- the elegant solution

[Eli Carter]

"Eric S. Raymond" wrote:
> 
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

And if the reason you are building a new kernel is that the old one is
mis-identifying some of your hardware? ;)

Could you maybe describe the problem you are trying to solve a bit more
clearly than "the hardware-discovery problem for ISA devices"?  If you
are trying to discover the ISA devices, but rely upon them having
already been discovered, what are you accomplishing?

Puzzled,

Eli
--------------------.     Real Users find the one combination of bizarre
Eli Carter           \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------

Re: ISA hardware discovery -- the elegant solution

[Wichert Akkerman]

In article <3C430E89.E65DCEDC@inet.com>,
Eli Carter  <eli.carter@inet.com> wrote:
>Could you maybe describe the problem you are trying to solve a bit more
>clearly than "the hardware-discovery problem for ISA devices"?  If you
>are trying to discover the ISA devices, but rely upon them having
>already been discovered, what are you accomplishing?

The problem is that it is simply not possible to identify ISA devices
if they aren't isapnp devices. The only thing you can do is try to
probe for them by poking at different addresses and checking what happens.
Unfortunately this can do any of three things: show that a piece of
hardware exists, show that it is not there or completely crash your
machine if another unpexpected piece of hardware happens to be at the 
place you are poking.

The best approach to doing ISA detection is ask the user which
devices he thinks he has installed and try looking for them while
praying bad things won't happen.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: ISA hardware discovery -- the elegant solution

[Oliver Xymoron]

On Mon, 14 Jan 2002, Eric S. Raymond wrote:

> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
>
> Yes, but this was always true.

No it's not. You only need a kernel that can run your compiler.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: ISA hardware discovery -- the elegant solution

[Tom Gilbert]

* Oliver Xymoron (oxymoron@waste.org) wrote:
> On Mon, 14 Jan 2002, Eric S. Raymond wrote:
> 
> > Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > > Doesn't this mean that you would need a fully functional kernel
> > > before you get to run the autoconfigurator?
> >
> > Yes, but this was always true.
> 
> No it's not. You only need a kernel that can run your compiler.

It's already been pointed out that the autconfigurator requires a great
many in-kernel features and userspace utilities.

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@linuxbrit.co.uk    |
  ^^-^^   `-------------------------------------------------------'

Re: ISA hardware discovery -- the elegant solution

[Andrew Pimlott]

On Mon, Jan 14, 2002 at 11:11:41AM -0500, Eric S. Raymond wrote:
> Michael Lazarou (ETL) <Michael.Lazarou@etl.ericsson.se>:
> > Doesn't this mean that you would need a fully functional kernel
> > before you get to run the autoconfigurator?
> 
> Yes, but this was always true.

I think the point people are getting at is:  If you're re-detecting
things that have already been detected, doesn't it seem you're going
about the problem the wrong way?

Most distributors need to solve essentially the same problem you're
solving (detect hardware and install drivers), but without compiling
a kernel (if only to spare the user the wait).  To the extent that
they are successful (and they will presumably put considerable
effort into it), your compile-time probes are superfluous--you're
better off piggy-backing on the distribution's hardware detection.
Eg, derive your .config from the modules the distribution has
decided to load, or--even simpler--just compile a kernel with the
same .config as the distributor's kernel, and let the boot-time
scripts take care of the rest.  The drawback is that this differs
across distributions--but see below.

Even if you can usually do a better job, you have two major
handicaps:  One, you may have to repeat questions that the
distribution already asked, annoying the user.  Two, if you ever
screw up something the distribution had working, the user will curse
you.

Which leads me to conclude that your compile-time autodetection,
while cool, is a dead-end as far as helping Cousin Billie (though I
do support the ultimate goal of letting him compile a kernel).
There are some scenarios where you win, but not enough IMO.

To correct this, retarget the project to solve the distributors'
problem.  Ie, add a back-end that specifies modules and module
options, instead of a kernel .config.  Assuming you do a good enough
job, and meet the distributor's other requirements (eg, running in
an install environment), then they will use your system for their
install-time hardware detection.  You can store the results in a
standard (across distributions!) format, which administrators will
love (and which can be used by various to-be-written utilities).
Finally, you can later use the same database for compiling a
"stripped-down" custom kernel.

Andrew

Re: ISA hardware discovery -- the elegant solution

[Zwane Mwaikambo]

You haven't taken into consideration that not many distributions have
drivers in kernel, and in particular ISA device drivers. Namely because
ISA probes are ugly and require frobbing of memory in the vague hopes of
finding said device there. These probes may put ye old ISA device in a bad
state sometimes even hard locking your box, so chances are if the ISA
probe is in dmesg, the user explicitely decided to load the device. In
which case they already know what they have...

As an aside, i try not to use ISA and elegant in the same sentence ;)

Regards,
	Zwane Mwaikambo

Re: ISA hardware discovery -- the elegant solution

[Alan Cox]

> You haven't taken into consideration that not many distributions have
> drivers in kernel, and in particular ISA device drivers. Namely because
> ISA probes are ugly and require frobbing of memory in the vague hopes of

Red Hat for one basically avoids ISA probing in favour of user guidance. We
also use a standard kernel build and the more I think about this the more
I think Erik's tool is trying to be too clever and should simply build 
a complete kernel set for the right cpu with the root fs and root fs block
device built into it

Re: ISA hardware discovery -- the elegant solution

[Zwane Mwaikambo]

On Mon, 14 Jan 2002, Alan Cox wrote:
> Red Hat for one basically avoids ISA probing in favour of user guidance. We
> also use a standard kernel build and the more I think about this the more
> I think Erik's tool is trying to be too clever and should simply build
> a complete kernel set for the right cpu with the root fs and root fs block
> device built into it

I'm definately not a fan of automagic kernel configurations, there are way
too many variables. Frankly the way i see it distro kernels do a damn good
job as it is right now and i don't see anything wrong with going the RH
errata kernel style for upgrading kernels (ditto for Debian and their apt
kernel upgrades). All Aunt Tillie has to do is click on the update button.

Are ISA device questions really that much of a big problem? The way i see
it, the user would get flooded more with the plethora of PCI and USB
devices more than anything. Then again i might be missing the "Big
Picture" ;)

Regards,
	Zwane Mwaikambo

ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

I've been thinking about the hardware-discovery problem for ISA devices,
and there may be an elegant solution.  It will take a number of small changes
to the kernel sources, however.

The kernel's device drivers have, of course, to include probe
routines, and those hard-compiled in typically log the presence of
their hardware to /var/log/mesg when it loads.  By scanning that
file, we in effect get to use those probes.

My autoconfigurator's probe table now has a small number of tests than 
do regexp matches against the dmesg log.  As is, this solution does not
scale well, because each regexp has to be discovered by eyeball and then
maintained in the table by hand.

But suppose the format of boot-time driver messages were standardized in a
format that included their config symbol in a discoverable form?

I have hand-edited a copy of my current /var/log/dmesg to illustrate
how I think this could work.  

:MTRR: your CPUs had inconsistent fixed MTRR settings
:MTRR: probably your BIOS does not setup all CPUs
:PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
:PCI: Using configuration type 1
:PCI: Probing PCI hardware
BIOS disabled PCI ordering compliance, so we enabled it again.
:IO_APIC: AMD Errata #22 may be present. In the event of instability try
        : booting with the "noapic" option.
:NET: Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
:RTNETLINK: Initializing RT netlink socket
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces
:JBD: Journalled Block Device driver loaded
:UNIX_PTY: 2048 Unix98 ptys configured
block: 128 slots per queue, batch=32
:IDE: Uniform Multi-Platform E-IDE driver Revision: 6.31
:IDE: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
:SCSI: SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

  Vendor: IBM-PSG   Model: ST318451LW    !#  Rev: B833
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: IBM-PSG   Model: ST318451LW    !#  Rev: B833
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: HP        Model: C5683A            Rev: C005
  Type:   Sequential-Access                  ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi0:A:1:0: Tagged Queuing enabled.  Depth 253
  Vendor: PIONEER   Model: DVD-ROM DVD-305   Rev: 1.00
  Type:   CD-ROM                             ANSI SCSI revision: 02
  Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35548320 512-byte hdwr sectors (18201 MB)
Partition check:
 sda: sda1 sda2 < sda5 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35548320 512-byte hdwr sectors (18201 MB)
 sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
:USB_DEVFS: registered new driver usbdevfs
:USB: registered new driver hub
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 96k freed
Adding Swap: 1807272k swap-space (priority -1)
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,5), internal journal
:BLK_DEV_MD: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kjournald starting.  Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,18), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:BLK_DEV_ST: Version 20011103, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0

The convention I propose is that at least one line of a driver probe message
should begin with :, followed by the driver config symbol, followed by :.
I am not attached to that particular punctuation, it is simply an unambiguous
way of indicating "this is a config symbol".

With this change, generating a report on ISA hardware and other
facilities configured in at boot time would be trivial.  This would
make the autoconfigurator much more capable.  Best of all, the only
change required to accomplish this would be safe edits of print format
strings.

I would be willing to generate a patch to implement this change.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
	-- Lazarus Long 

Re: ISA hardware discovery -- the elegant solution

[Larry McVoy]

> :MTRR: your CPUs had inconsistent fixed MTRR settings
> :MTRR: probably your BIOS does not setup all CPUs
> :PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
> :PCI: Using configuration type 1
> :PCI: Probing PCI hardware

It's ugly and distracting and if this proposal goes anywhere, move the tag to 
end of the line.  Then your eyes can scan the output and the tools can scan
the end of the line.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: ISA hardware discovery -- the elegant solution

[Eric W. Biederman]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> I've been thinking about the hardware-discovery problem for ISA devices,
> and there may be an elegant solution.  It will take a number of small changes
> to the kernel sources, however.

An elegant solution is writing a program like kudzu and placing the
information it generates in a globally accessible place.  The problem
is that linux does really have a complete standard hardware database,
and until such a thing is built there are no short cuts, no easy methods
to get it.  And there probably never will be guaranteed unprivledged
user space access to the information.  The system administrator may
simply not want to let that information go.

The only thing that comes close to what you currently want is
devfs.

dmesg is for people.

As for ISA there is a reason even the enhance version that allows
software discovery is called Plug-and-Pray.


> My autoconfigurator's probe table now has a small number of tests than 
> do regexp matches against the dmesg log.  As is, this solution does not
> scale well, because each regexp has to be discovered by eyeball and then
> maintained in the table by hand.

ISA is not a software enumerable bus especially not for unprivledged
users.  And no amount of complaining will change that.  That is why we
have PNP ISA and PCI.

> But suppose the format of boot-time driver messages were standardized in a
> format that included their config symbol in a discoverable form?

If there was an ISA device in your example it might be interesting.

> With this change, generating a report on ISA hardware and other
> facilities configured in at boot time would be trivial.  This would
> make the autoconfigurator much more capable.  Best of all, the only
> change required to accomplish this would be safe edits of print format
> strings.

It sounds like what you want is an lsmod that lists compiled in
modules.

> I would be willing to generate a patch to implement this change.

Please don't until you understand the problem...

Eric

Re: ISA hardware discovery -- the elegant solution

[Eric S. Raymond]

Eric W. Biederman <ebiederm@xmission.com>:
> ISA is not a software enumerable bus especially not for unprivledged
> users.  And no amount of complaining will change that.  That is why we
> have PNP ISA and PCI.

But the kernel itself has to know how to probe and initialize these devices
at boot time, correct?  That information is implicitly exported via
/var/log/dmesg -- I'm simply suggesting that it be a little more explicit.

> > But suppose the format of boot-time driver messages were standardized in a
> > format that included their config symbol in a discoverable form?
> 
> If there was an ISA device in your example it might be interesting.

Some of the on-board devices on my Tyan Thunder are ISA.

> > With this change, generating a report on ISA hardware and other
> > facilities configured in at boot time would be trivial.  This would
> > make the autoconfigurator much more capable.  Best of all, the only
> > change required to accomplish this would be safe edits of print format
> > strings.
> 
> It sounds like what you want is an lsmod that lists compiled in
> modules.

Would that be feasible without root privileges in order to read kmem?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

[The disarming of citizens] has a double effect, it palsies the hand
and brutalizes the mind: a habitual disuse of physical forces totally
destroys the moral [force]; and men lose at once the power of
protecting themselves, and of discerning the cause of their
oppression.
        -- Joel Barlow, "Advice to the Privileged Orders", 1792-93

Re: ISA hardware discovery -- the elegant solution

[H. Peter Anvin]

Followup to:  <20020114034831.A5780@thyrsus.com>
By author:    "Eric S. Raymond" <esr@thyrsus.com>
In newsgroup: linux.dev.kernel
> 
> But the kernel itself has to know how to probe and initialize these devices
> at boot time, correct?  That information is implicitly exported via
> /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.
> 

dmesg is lossy.  Don't assume it is complete.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: ISA hardware discovery -- the elegant solution

[Eric W. Biederman]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Eric W. Biederman <ebiederm@xmission.com>:
> > ISA is not a software enumerable bus especially not for unprivledged
> > users.  And no amount of complaining will change that.  That is why we
> > have PNP ISA and PCI.
> 
> But the kernel itself has to know how to probe and initialize these devices
> at boot time, correct?  That information is implicitly exported via
> /var/log/dmesg -- I'm simply suggesting that it be a little more explicit.

For ISA not necessarily.  It could simply be told that it was there.
/etc/modules.conf or it's compile time equivalent.
 
> > > But suppose the format of boot-time driver messages were standardized in a
> > > format that included their config symbol in a discoverable form?
> > 
> > If there was an ISA device in your example it might be interesting.
> 
> Some of the on-board devices on my Tyan Thunder are ISA.

I agree that ISA is a case.  I simply didn't see it.  And that was
my real point.  Usually we are pretty silent about most ISA devices in
dmesg, because of most of them are mandated by the PC architecture and
we just expect them to be there.
 
> > > With this change, generating a report on ISA hardware and other
> > > facilities configured in at boot time would be trivial.  This would
> > > make the autoconfigurator much more capable.  Best of all, the only
> > > change required to accomplish this would be safe edits of print format
> > > strings.
> > 
> > It sounds like what you want is an lsmod that lists compiled in
> > modules.
> 
> Would that be feasible without root privileges in order to read kmem?

Given that nothing in the linux world reads kmem... 

Honestly you have two separate problems.
Problem 1:  How do you find out all of the hardware you have, as root.
Problem 2:  How do you get that information as non-root.

Please try solving these problems separately.

Eric

module unresolved symbols

[rich+ml]

Hi all, kindly redirect me if this is the wrong list.

Starting with a stock RH 7.0 install, I changed a single kernel config
item and recompiled with 'make defs clean bzImage modules
modules_install'.

Booted on the new kernel and depmod complains that dozens of modules
contain unresolved symbols. Back to the original kernel, now it also
complains of unresolved symbols (not the same set of modules, and modules
that were previously OK).

I can't find an answer on the net, does anyone know how to fix this?

Thanks == Rich

Re: module unresolved symbols

[Jesse Pollard]

On Sat, 04 Aug 2001, rich+ml@lclogic.com wrote:
>Hi all, kindly redirect me if this is the wrong list.
>
>Starting with a stock RH 7.0 install, I changed a single kernel config
>item and recompiled with 'make defs clean bzImage modules
>modules_install'.
>
>Booted on the new kernel and depmod complains that dozens of modules
>contain unresolved symbols. Back to the original kernel, now it also
>complains of unresolved symbols (not the same set of modules, and modules
>that were previously OK).
>
>I can't find an answer on the net, does anyone know how to fix this?
>
>Thanks == Rich

This id due to the change in parameters and kernel rebuild. The default
kernel used a different configuration than the one in the src directory,
even though the kernel name was the same.

What I do to keep this from happening is to change the "EXTRAVERSION" in the
src/linux/Makefile.

As long as this is different from the distributed kernel name then a new
/lib/modules/xxx/... directory will be created. That directory will contain
the new modules instead of the default one.

To repair the damage, you will need your backup (or reload them from the
distribution).

An alternative - If you copied the src tree before changing the configuration
you can try a "make modules_install" in the original directory. This IS
assuming that that tree is the one used for the default kernel.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: module unresolved symbols

[Steven Walter]

On Sat, Aug 04, 2001 at 05:39:17PM -0700, rich+ml@lclogic.com wrote:
> Hi all, kindly redirect me if this is the wrong list.
> 
> Starting with a stock RH 7.0 install, I changed a single kernel config
> item and recompiled with 'make defs clean bzImage modules
> modules_install'.
> 
> Booted on the new kernel and depmod complains that dozens of modules
> contain unresolved symbols. Back to the original kernel, now it also
> complains of unresolved symbols (not the same set of modules, and modules
> that were previously OK).
> 
> I can't find an answer on the net, does anyone know how to fix this?
> 
> Thanks == Rich

For one, it should have been 'make deps clean bzImage modules'.
However, depending on the option you changed, a 'make mrproper' may have
been in order.  Be sure to back up your .config first, though
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: module unresolved symbols

[Keith Owens]

On Sat, 4 Aug 2001 17:39:17 -0700 (PDT), 
<rich+ml@lclogic.com> wrote:
>Starting with a stock RH 7.0 install, I changed a single kernel config
>item and recompiled with 'make defs clean bzImage modules
>modules_install'.
>
>Booted on the new kernel and depmod complains that dozens of modules
>contain unresolved symbols. Back to the original kernel, now it also
>complains of unresolved symbols (not the same set of modules, and modules
>that were previously OK).

Broken kernel makefiles when module symbols are turned on.
http://www.tux.org/lkml/#s8-8

Re: module unresolved symbols

[Horst von Brand]

Keith Owens <kaos@ocs.com.au> said:
> On Sat, 4 Aug 2001 17:39:17 -0700 (PDT), 
> <rich+ml@lclogic.com> wrote:
> >Starting with a stock RH 7.0 install, I changed a single kernel config
> >item and recompiled with 'make defs clean bzImage modules
> >modules_install'.

> >Booted on the new kernel and depmod complains that dozens of modules
> >contain unresolved symbols. Back to the original kernel, now it also
> >complains of unresolved symbols (not the same set of modules, and modules
> >that were previously OK).

> Broken kernel makefiles when module symbols are turned on.
> http://www.tux.org/lkml/#s8-8

Or leftover modules from the stock install.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: module unresolved symbols

[Keith Owens]

On Sun, 05 Aug 2001 12:06:50 -0400, 
Horst von Brand <vonbrand@sleipnir.valparaiso.cl> wrote:
>Keith Owens <kaos@ocs.com.au> said:
>> Broken kernel makefiles when module symbols are turned on.
>> http://www.tux.org/lkml/#s8-8
>
>Or leftover modules from the stock install.

Not with kernel 2.4.  I changed make modules_install to erase the old
kernel modules precisely to avoid this problem.