lkml.org 
[lkml]   [2000]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Installing kernel 2.4
Date
There is a variation of #2 that is often good enough, based on some research
work done at (among other places) the Oregon Graduate Center. I don't have
the references handy, but you might want to look for papers on "sandboxing"
authored there.

The basic idea is similar to the one used by many 'recompile on the fly'
systems, and involves marking the code in such a way that even inline pieces
can be replaced on the fly. Very useful for things like system specific
memcpy implementations.

Marty


> -----Original Message-----
> From: David Lang [mailto:david.lang@digitalinsight.com]
> Sent: Tuesday, November 07, 2000 4:11 PM
> To: Jeff V. Merkey
> Cc: kernel@kvack.org; Martin Josefsson; Tigran Aivazian; Anil kumar;
> linux-kernel@vger.kernel.org
> Subject: Re: Installing kernel 2.4
>
>
> Jeff, the problem is not detecting the CPU type at runtime,
> the problem is
> trying to re-compile the code to take advantage of that CPU
> at runtime.
>
> depending on what CPU you have the kernel (and compiler) can
> use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.
>
> 1. re-compile the kernel
>
> 2. change all the CPU specific places from inline code to
> function calls
> into a table that get changed at boot to point at the correct calls.
>
> doing #2 will cost you so much performance that you would be
> better off
> just compiling for a 386 and not going through the autodetect
> hassle in
> the first place.
>
> David Lang
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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