lkml.org 
[lkml]   [2003]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC: [2.6 patch] better i386 CPU selection
Date
In message <20030908142920.GB28062@fs.tum.de> you write:
> On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> > In message <20030907112813.GQ14436@fs.tum.de> you write:
> > > - @Rusty:
> > > what's your opinion on making MODULE_PROC_FAMILY in
> > > include/asm-i386/module.h some kind of bitmask?
> >
> > The current one is readable, which is good, and Linus asked for it,
> > which makes it kinda moot. And really, if you compile a module with
> > M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> > for CPU seleciton, I want the poor user to have to use "modprobe -f".
>
> I agree, my thoughts go in the direction
>
> bit 0 CPU_386
> bit 1 CPU_486
> bit 2 CPU_586

We had a bitmask, which Linus said to replace with a string. We have
21 architectures, and a string works well in practice. We could have
a bitmask *and* a string, but why the complexity?

> And you should need a "modprobe -f" if the bitmask in the module differs
> from the bitmask in the kernel.

All modprobe -f knows is that it should remove/rename various sections
from the elf object before handing it to the kernel. The checking is
done in the kernel, as it should be (so we could change this whenever
we want, for example).

Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.069 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site