On Thu, 09 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > I think a default whereby the kernel built will run on any
> > Linux-capable machine of that architecture would be sensible - so if I
> > grab the 2.4.0t10 tarball and build it now, with no changes, I'll be
> > able to
> I would like to see some features added to ELF. Resource binding support
> would be nice, i.e. bitmaps used internally by GUI apps and such, so
> that they can be shared between processes if they are in a shared lib,
You can do shared mappings of almost anything anyway. In fact most of the
[EMAIL PROTECTED] said:
> I think a default whereby the kernel built will run on any
> Linux-capable machine of that architecture would be sensible - so if I
> grab the 2.4.0t10 tarball and build it now, with no changes, I'll be
> able to boot the kernel on any x86 machine.
I have four
"Jeff V. Merkey" wrote:
> > The kernel isn't going non-ELF. Too painful, for dubious advantages,
> > namely:
> >
>
> perhaps we should extend ELF. After all, where linux goes, gcc
> follows
I would like to see some features added to ELF. Resource binding support
would be nice, i.e.
"Jeff V. Merkey" wrote:
The kernel isn't going non-ELF. Too painful, for dubious advantages,
namely:
perhaps we should extend ELF. After all, where linux goes, gcc
follows
I would like to see some features added to ELF. Resource binding support
would be nice, i.e. bitmaps used
[EMAIL PROTECTED] said:
I think a default whereby the kernel built will run on any
Linux-capable machine of that architecture would be sensible - so if I
grab the 2.4.0t10 tarball and build it now, with no changes, I'll be
able to boot the kernel on any x86 machine.
I have four machines on
I would like to see some features added to ELF. Resource binding support
would be nice, i.e. bitmaps used internally by GUI apps and such, so
that they can be shared between processes if they are in a shared lib,
You can do shared mappings of almost anything anyway. In fact most of the
shared
On Thu, 09 Nov 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
I think a default whereby the kernel built will run on any
Linux-capable machine of that architecture would be sensible - so if I
grab the 2.4.0t10 tarball and build it now, with no changes, I'll be
able to boot the
On Wed, 08 Nov 2000, George Anzinger wrote:
> "James A. Sutherland" wrote:
> >
> > On Wed, 08 Nov 2000, George Anzinger wrote:
> > > But, here the customer did run the configure code (he said he did not
> > > change anything). Isn't this where the machine should be diagnosed and
> > > the right
"James A. Sutherland" wrote:
>
> On Wed, 08 Nov 2000, George Anzinger wrote:
> > But, here the customer did run the configure code (he said he did not
> > change anything). Isn't this where the machine should be diagnosed and
> > the right options chosen? Need a way to say it is a cross build,
On Wed, 08 Nov 2000, George Anzinger wrote:
> But, here the customer did run the configure code (he said he did not
> change anything). Isn't this where the machine should be diagnosed and
> the right options chosen? Need a way to say it is a cross build, but
> that shouldn't be too hard.
Why
It might be convenient to have a completely unoptimized 386 kernel. While
this would obviously be non-optimal in all cases, it would be compatible
with everything and probably faster on non-386 than a 386-optimized
kernel. Of course, the gains are probably not worth the time it would take
On Wed, Nov 08, 2000 at 08:49:15AM -0500, [EMAIL PROTECTED] wrote:
>
> >
> > On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> > > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > >
> > > > If the compiler always aligned all functions and data on 16 byte
> > > > boundries
On Wed, Nov 08, 2000 at 07:43:29AM -0600, Jesse Pollard wrote:
> - Received message begins Here -
>
> >
> > On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> > > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > >
> > > > If the compiler always aligned all
But, here the customer did run the configure code (he said he did not
change anything). Isn't this where the machine should be diagnosed and
the right options chosen? Need a way to say it is a cross build, but
that shouldn't be too hard.
My $.02 worth.
George
"James A. Sutherland" wrote:
>
On Wed, 08 Nov 2000, Horst von Brand wrote:
> "Jeff V. Merkey" <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Your way out in the weeds. What started this thread was a customer who
> > ended up loading the wrong arch on a system and hanging. I have to
> > post a kernel RPM for our release, and
Horst von Brand <[EMAIL PROTECTED]> writes:
> I'd prefer to be a guinea pig for one of 3 or 4 generic kernels distributed
> in binary than of one of the hundreds of possibilities of patching a kernel
> together at boot, plus the (presumamby rather complex and fragile)
> machinery to do so
On Wed, 8 Nov 2000 [EMAIL PROTECTED] wrote:
> > On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> > > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > > > If the compiler always aligned all functions and data on 16 byte
> > > > boundries (NetWare) for all i386 code, it would run
>
> On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> >
> > > If the compiler always aligned all functions and data on 16 byte
> > > boundries (NetWare) for all i386 code, it would run a lot faster.
> >
> > Except on architectures
- Received message begins Here -
>
> On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> >
> > > If the compiler always aligned all functions and data on 16 byte
> > > boundries (NetWare) for all i386 code, it
"Jeff V. Merkey" <[EMAIL PROTECTED]> said:
[...]
> Your way out in the weeds. What started this thread was a customer who
> ended up loading the wrong arch on a system and hanging. I have to
> post a kernel RPM for our release, and it's onerous to make customers
> recompile kernels all the
"Jeff V. Merkey" [EMAIL PROTECTED] said:
[...]
Your way out in the weeds. What started this thread was a customer who
ended up loading the wrong arch on a system and hanging. I have to
post a kernel RPM for our release, and it's onerous to make customers
recompile kernels all the time and
On Wed, 8 Nov 2000 [EMAIL PROTECTED] wrote:
On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
If the compiler always aligned all functions and data on 16 byte
boundries (NetWare) for all i386 code, it would run a lot
Horst von Brand [EMAIL PROTECTED] writes:
I'd prefer to be a guinea pig for one of 3 or 4 generic kernels distributed
in binary than of one of the hundreds of possibilities of patching a kernel
together at boot, plus the (presumamby rather complex and fragile)
machinery to do so *before* the
On Wed, 08 Nov 2000, Horst von Brand wrote:
"Jeff V. Merkey" [EMAIL PROTECTED] said:
[...]
Your way out in the weeds. What started this thread was a customer who
ended up loading the wrong arch on a system and hanging. I have to
post a kernel RPM for our release, and it's onerous to
On Wed, Nov 08, 2000 at 07:43:29AM -0600, Jesse Pollard wrote:
- Received message begins Here -
On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
If the compiler always aligned all functions and data
On Wed, Nov 08, 2000 at 08:49:15AM -0500, [EMAIL PROTECTED] wrote:
On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
If the compiler always aligned all functions and data on 16 byte
boundries (NetWare) for all i386
It might be convenient to have a completely unoptimized 386 kernel. While
this would obviously be non-optimal in all cases, it would be compatible
with everything and probably faster on non-386 than a 386-optimized
kernel. Of course, the gains are probably not worth the time it would take
On Wed, 08 Nov 2000, George Anzinger wrote:
But, here the customer did run the configure code (he said he did not
change anything). Isn't this where the machine should be diagnosed and
the right options chosen? Need a way to say it is a cross build, but
that shouldn't be too hard.
Why
"James A. Sutherland" wrote:
On Wed, 08 Nov 2000, George Anzinger wrote:
But, here the customer did run the configure code (he said he did not
change anything). Isn't this where the machine should be diagnosed and
the right options chosen? Need a way to say it is a cross build, but
On Wed, 08 Nov 2000, George Anzinger wrote:
"James A. Sutherland" wrote:
On Wed, 08 Nov 2000, George Anzinger wrote:
But, here the customer did run the configure code (he said he did not
change anything). Isn't this where the machine should be diagnosed and
the right options
On Tue, Nov 07, 2000 at 06:18:09PM -0800, H. Peter Anvin wrote:
> Jeff Garzik wrote:
> >
> > "Jeff V. Merkey" wrote:
> > > We need a format that allow multiple executable segments to be combined
> > > in a single executable and the loader have enough smarts to grab the
> > > right one based on
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> Your way out in the weeds. What started this thread was a customer who
> ended up loading the wrong arch on a system and hanging. I have to
> post a kernel RPM for our release, and it's onerous to make customers
> recompile kernels all the time and
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> What makes more sense is to pack multiple segments for different
> processor architecures into a single executable package, and have the
> loader pick the right one (the NT model). It could be used for
> SMP and non-SMP images, though, as well as
On Wed, Nov 08, 2000 at 03:39:39AM +, [EMAIL PROTECTED] wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> > > remember it's not just the start of the file that varies based on cachline
> > > size, it's the positioning of code and data thoughout the kernel image.
> > Understood. I will
On Tue, 7 Nov 2000, Marty Fouts wrote:
> There's been a bunch of related work done at the Oregon Graduate Institute
> by Calton Pu and others. See
> http://www.cse.ogi.edu/DISC/projects/synthetix/publications.html for a list
> of papers.
The only paper that immediately caught my eye of
On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> > If the compiler always aligned all functions and data on 16 byte
> > boundries (NetWare) for all i386 code, it would run a lot faster.
>
> Except on architectures where 16 byte
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > remember it's not just the start of the file that varies based on cachline
> > size, it's the positioning of code and data thoughout the kernel image.
> Understood. I will go off and give some thought and study and respond
> later after I have a
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
(Please forgive this snippage making Jeff look less literate
than he is, even after several beers.)
> We need a format that allow
[..]
> the right one based on architecture.
Oh, we already have that. It's called source code.
Matthew.
-
To
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > > Detecting the CPU isn't the issue (we already do all this), it's what to
> > > do when you've figured out what the CPU is. Show me code that can
> > > dynamically adjust the alignment of the routines/variables/structs
> > > dependant upon cacheline
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> If the compiler always aligned all functions and data on 16 byte
> boundries (NetWare) for all i386 code, it would run a lot faster.
Except on architectures where 16 byte alignment isn't optimal.
> Cache line alignment could be an option in the
: Tuesday, November 07, 2000 3:25 PM
> To: Linux Kernel Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
>
>
>
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of
&g
> Sent: Tuesday, November 07, 2000 4:11 PM
> To: Jeff V. Merkey
> Cc: [EMAIL PROTECTED]; Martin Josefsson; Tigran Aivazian; Anil kumar;
> [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
>
>
> Jeff, the problem is not detecting the CPU type at runtime,
> the problem
Jeff Garzik wrote:
>
> "Jeff V. Merkey" wrote:
> > We need a format that allow multiple executable segments to be combined
> > in a single executable and the loader have enough smarts to grab the
> > right one based on architecture. two options:
> >
> > 1. extend gcc to support this or
Alan Cox wrote:
>
> > I'll grab the code in linux and port.
>
> You are welcome
>
> Make sure you get a pretty current 2.2.x tree however. The ultra deep magic
> for detecting NexGen processors is recent. It took a long time before I found
> someone who knew how it worked 8)
I'll get on it.
> We need a format that allow multiple executable segments to be combined
> in a single executable and the loader have enough smarts to grab the
> right one based on architecture. two options:
ELF can do that just fine
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> I'll grab the code in linux and port.
You are welcome
Make sure you get a pretty current 2.2.x tree however. The ultra deep magic
for detecting NexGen processors is recent. It took a long time before I found
someone who knew how it worked 8)
-
To unsubscribe from this list: send the line
Jeff Garzik wrote:
>
> Jeff Merkey wrote:
> > The PE model uses flags to identify CPU type and capbilities
>
> So does ELF.
Jeff,
Can we also combine mutiple segments from different processors or is it
a one-sy two-sy king of affair? If so, we're there, it just becomes a
linking option.
I
Alan Cox wrote:
>
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > be dynamic. Here's some code that does this, and it's similiar to
> > NetWare. It detexts CPU type, feature flags, special
Jeff Merkey wrote:
> The PE model uses flags to identify CPU type and capbilities
So does ELF.
--
Jeff Garzik | "When I do this, my computer freezes."
Building 1024 | -user
MandrakeSoft| "Don't do that."
| -level 1
-
> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings. All of this could
> be dynamic. Here's some code that does this, and it's similiar to
> NetWare. It detexts CPU type, feature flags, special instructions,
> etc. All of this
David Relson wrote:
>
> It seems to me that kernel/cpu matching can be broken into two relatively
> simple parts.
>
> 1 - Put a cpu "signature" in the kernel image indicating cpu requirements; and
> 2 - Have the bootloader (lilo) detect cpu type and match it against the cpu
> "signature".
>
It seems to me that kernel/cpu matching can be broken into two relatively
simple parts.
1 - Put a cpu "signature" in the kernel image indicating cpu requirements; and
2 - Have the bootloader (lilo) detect cpu type and match it against the cpu
"signature".
The bootloader would then load the
Jeff Garzik wrote:
>
> "Jeff V. Merkey" wrote:
> > We need a format that allow multiple executable segments to be combined
> > in a single executable and the loader have enough smarts to grab the
> > right one based on architecture. two options:
> >
> > 1. extend gcc to support this or
David Lang
>
> On Tue, 7 Nov
> 2000, Jeff V. Merkey wrote:
>
> > Date: Tue, 07 Nov 2000 16:47:08 -0700
> > From: Jeff V. Merkey <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED], Linux Kernel Mailing List <[EMAIL PROTECTED]>
> > Subject: Re: Inst
"Jeff V. Merkey" wrote:
> We need a format that allow multiple executable segments to be combined
> in a single executable and the loader have enough smarts to grab the
> right one based on architecture. two options:
>
> 1. extend gcc to support this or rearragne linux into segments based on
>
Code is. Data isn't. Gcc packs data into the segment like sardines in
a can (NT code does to). 16 byte align this as well. NetWare 16 byte
aligns everythin with an align 16 directive in the data segments of
assembler modules.
Jeff
Jeff Garzik wrote:
>
> "Jeff V. Merkey" wrote:
> > If the
Date: Tue, 07 Nov 2000 16:47:08 -0700
> From: Jeff V. Merkey <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], Linux Kernel Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Installing kernel 2.4
>
>
>
> "Jeff V. Merkey" wrote:
> >
> >
Jeff Garzik wrote:
>
> Jeff Merkey wrote:
> > here are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > be dynamic. Here's some code that does this, and it's similiar to
> > NetWare. It detexts CPU type,
"Jeff V. Merkey" wrote:
> If the compiler always aligned all functions and data on 16 byte
> boundries (NetWare)
> for all i386 code, it would run a lot faster.
Are you saying that it isn't? Have you look at gcc-generated assembly
from a recent 2.2.x or 2.4.x kernel?
2.2.x build command line,
Sven Koch wrote:
>
> On Tue, 7 Nov 2000, David Lang wrote:
>
> > 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.
>
> Wouldn't it be possible to compile the parts of the kernel
Jeff Merkey wrote:
> here are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings. All of this could
> be dynamic. Here's some code that does this, and it's similiar to
> NetWare. It detexts CPU type, feature flags, special instructions,
>
On Tue, 7 Nov 2000, David Lang wrote:
> 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.
Wouldn't it be possible to compile the parts of the kernel needed to
uncompress and to detect the
"Jeff V. Merkey" wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > > There are tests for all this in the feature flags for intel and
> > > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > > be dynamic. Here's some code that does this, and it's similiar to
> > > NetWare.
. Merkey wrote:
>
> > Date: Tue, 07 Nov 2000 16:10:58 -0700
> > From: Jeff V. Merkey <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: Martin Josefsson <[EMAIL PROTECTED]>,
> > Tigran Aivazian <[EMAIL PROTECTED]>, Anil kumar <[EMAIL
[EMAIL PROTECTED] wrote:
>
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > be dynamic. Here's some code that does this, and it's similiar to
> > NetWare. It detexts CPU type, feature flags,
[EMAIL PROTECTED]>, Anil kumar <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
>
>
> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings. All of this could
> be
> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings. All of this could
> be dynamic. Here's some code that does this, and it's similiar to
> NetWare. It detexts CPU type, feature flags, special instructions,
> etc. All of
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags, special instructions,
etc. All of this on x86
"Jeff V. Merkey" wrote:
> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it? Come on guys.
Linux detects this as well -
However this is not about detection, but optimizations.
Optimizations e.g. for xeon could keep a K6/2 from
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it? Come on guys.
Then run a kernel compiled for i386 and suffer the poorer code quality
that comes with not using newer instructions and
L PROTECTED]>, Anil kumar
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
11/07/2000 05:32 PM Subje
On Tue, 07 Nov 2000 23:32:46 Jeff V. Merkey wrote:
>
> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it? Come on guys.
>
If you can get NT to boot on a 486, perhaps that shows that NT does not use
any optimization...so does not
So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it? Come on guys.
Jeff
Martin Josefsson wrote:
>
> On Tue, 7 Nov 2000, Tigran Aivazian wrote:
>
> > On Tue, 7 Nov 2000, Anil kumar wrote:
> > > The system hangs after messages:
> >
On Tue, 7 Nov 2000, Tigran Aivazian wrote:
> On Tue, 7 Nov 2000, Anil kumar wrote:
> > The system hangs after messages:
> > loading linux..
> > uncompressing linux, booting linux kernel OK.
> >
> > The System hangs here.
> >
> > Please let me know where I am wrong
>
> Hi Anil,
>
On Tue, 7 Nov 2000, Anil kumar wrote:
> The system hangs after messages:
> loading linux..
> uncompressing linux, booting linux kernel OK.
>
> The System hangs here.
>
> Please let me know where I am wrong
Hi Anil,
The only serious mistake you did was using test9 kernel when
Anil kumar wrote:
>
> Hi ,
> I installed Red Hat 7.0, I am able to find the
> linux-2.2.16 in /usr/src
>
> These are the following steps I did to install
> kernel 2.4:
>
> cd /usr/src
> #rm -r linux
># rm -rf linux-2.2.16
>#tar -xvf linux-2.4.0-test9.tar
>
> #cd
Anil kumar wrote:
Hi ,
I installed Red Hat 7.0, I am able to find the
linux-2.2.16 in /usr/src
These are the following steps I did to install
kernel 2.4:
cd /usr/src
#rm -r linux
# rm -rf linux-2.2.16
#tar -xvf linux-2.4.0-test9.tar
#cd /usr/src
#ls
linux
On Tue, 7 Nov 2000, Anil kumar wrote:
The system hangs after messages:
loading linux..
uncompressing linux, booting linux kernel OK.
The System hangs here.
Please let me know where I am wrong
Hi Anil,
The only serious mistake you did was using test9 kernel when
On Tue, 7 Nov 2000, Tigran Aivazian wrote:
On Tue, 7 Nov 2000, Anil kumar wrote:
The system hangs after messages:
loading linux..
uncompressing linux, booting linux kernel OK.
The System hangs here.
Please let me know where I am wrong
Hi Anil,
The only
So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it? Come on guys.
Jeff
Martin Josefsson wrote:
On Tue, 7 Nov 2000, Tigran Aivazian wrote:
On Tue, 7 Nov 2000, Anil kumar wrote:
The system hangs after messages:
loading
On Tue, 07 Nov 2000 23:32:46 Jeff V. Merkey wrote:
So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it? Come on guys.
If you can get NT to boot on a 486, perhaps that shows that NT does not use
any optimization...so does not
On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it? Come on guys.
Then run a kernel compiled for i386 and suffer the poorer code quality
that comes with not using newer instructions and
[EMAIL PROTECTED],
[EMAIL PROTECTED]
11/07/2000 05:32 PM Subject: Re: Installing k
"Jeff V. Merkey" wrote:
So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it? Come on guys.
Linux detects this as well -
However this is not about detection, but optimizations.
Optimizations e.g. for xeon could keep a K6/2 from
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags, special instructions,
etc. All of this on x86
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags, special instructions,
etc. All of this on
PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Installing kernel 2.4
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts
[EMAIL PROTECTED] wrote:
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags, special
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Martin Josefsson [EMAIL PROTECTED],
Tigran Aivazian [EMAIL PROTECTED], Anil kumar [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Installing kernel 2.4
There are tests for all this in the feature flags for intel and
non-intel CPUs
"Jeff V. Merkey" wrote:
[EMAIL PROTECTED] wrote:
There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU
On Tue, 7 Nov 2000, David Lang wrote:
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.
Wouldn't it be possible to compile the parts of the kernel needed to
uncompress and to detect the
Jeff Merkey wrote:
here are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags, special instructions,
etc.
Sven Koch wrote:
On Tue, 7 Nov 2000, David Lang wrote:
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.
Wouldn't it be possible to compile the parts of the kernel needed to
"Jeff V. Merkey" wrote:
If the compiler always aligned all functions and data on 16 byte
boundries (NetWare)
for all i386 code, it would run a lot faster.
Are you saying that it isn't? Have you look at gcc-generated assembly
from a recent 2.2.x or 2.4.x kernel?
2.2.x build command line,
Jeff Garzik wrote:
Jeff Merkey wrote:
here are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings. All of this could
be dynamic. Here's some code that does this, and it's similiar to
NetWare. It detexts CPU type, feature flags,
Nov 2000 16:47:08 -0700
From: Jeff V. Merkey [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Linux Kernel Mailing List [EMAIL PROTECTED]
Subject: Re: Installing kernel 2.4
"Jeff V. Merkey" wrote:
[EMAIL PROTECTED] wrote:
There are tests for all this in the feature flags
Code is. Data isn't. Gcc packs data into the segment like sardines in
a can (NT code does to). 16 byte align this as well. NetWare 16 byte
aligns everythin with an align 16 directive in the data segments of
assembler modules.
Jeff
Jeff Garzik wrote:
"Jeff V. Merkey" wrote:
If the
"Jeff V. Merkey" wrote:
We need a format that allow multiple executable segments to be combined
in a single executable and the loader have enough smarts to grab the
right one based on architecture. two options:
1. extend gcc to support this or rearragne linux into segments based on
code
:
Date: Tue, 07 Nov 2000 16:47:08 -0700
From: Jeff V. Merkey [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Linux Kernel Mailing List [EMAIL PROTECTED]
Subject: Re: Installing kernel 2.4
"Jeff V. Merkey" wrote:
[EMAIL PROTECTED] wrote:
There are tests for all this in t
1 - 100 of 123 matches
Mail list logo
