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
> 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
shar
[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
"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
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 d
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
to
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
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 funct
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 it's
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
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 wou
"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 tim
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 ar
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 be
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 i3
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 g
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 relevanc
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 a
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 prop
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 unsubscribe
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 loade
Sent: 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 o
AIL PROTECTED]]
> 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,
&
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 rearragn
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
> 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 "un
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 instr
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
-
To
> 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 ker
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 rearra
).
Jeff
> 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]>
> > Su
"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 c
y 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: 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, featu
"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, n
"Jeff V. Merkey" wrote:
>
> "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,
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 neede
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. It
. 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 PROTECTE
[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, spec
[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 dyn
> 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
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 co
"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 boo
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 inc
[EMAIL PROTECTED]>, Anil kumar
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
11/07/2000 05:32 PM
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 w
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 test
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
64 matches
Mail list logo
