Re: Installing kernel 2.4
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 kernel on any x86 machine. > > I have four machines on my desk at the moment. The workstation is a dual > P-III. I suppose I agree that it might be nice if the kernel for that also > worked on the embedded 386 board. But it'd also be nice if it worked on the > Alpha and the SH boards which are also on my desk. How about putting the > whole lot into a single kernel image? It's the logical extension of what's > being suggested. No. In the x86 case, it is a question of "do we deliberately restrict this kernel to running only on a Pentium II in order to make it x% faster". My suggestion does not duplicate any code, or (with a few exceptions) include any redundant code for any platform (maths emulation, e.g., would be an exception). Yours duplicates code, rather than just not optimising it as aggressively. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
> 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 library loading is done in user space via mmap. There are good reasons for not putting resources into the program itself too, one of which is customisability. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
[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 my desk at the moment. The workstation is a dual P-III. I suppose I agree that it might be nice if the kernel for that also worked on the embedded 386 board. But it'd also be nice if it worked on the Alpha and the SH boards which are also on my desk. How about putting the whole lot into a single kernel image? It's the logical extension of what's being suggested. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 internally by GUI apps and such, so that they can be shared between processes if they are in a shared lib, and so that the app can reload faster if the resources are cached. I suspect this is what allows netscape to restart in < 2 sec under Windows or OS/2, versus ~5 sec under Linux on the same system. Executable signing or at least a CRC (optional, of course) would be nice too. Version strings would be helpful in some cases as well (like bad programs that don't/can't support the -v|-V|--version options, or for automated retrieval of the information) Sorry if these features are supported already. -- Mark McClelland [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 internally by GUI apps and such, so that they can be shared between processes if they are in a shared lib, and so that the app can reload faster if the resources are cached. I suspect this is what allows netscape to restart in 2 sec under Windows or OS/2, versus ~5 sec under Linux on the same system. Executable signing or at least a CRC (optional, of course) would be nice too. Version strings would be helpful in some cases as well (like bad programs that don't/can't support the -v|-V|--version options, or for automated retrieval of the information) Sorry if these features are supported already. -- Mark McClelland [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
[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 my desk at the moment. The workstation is a dual P-III. I suppose I agree that it might be nice if the kernel for that also worked on the embedded 386 board. But it'd also be nice if it worked on the Alpha and the SH boards which are also on my desk. How about putting the whole lot into a single kernel image? It's the logical extension of what's being suggested. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 library loading is done in user space via mmap. There are good reasons for not putting resources into the program itself too, one of which is customisability. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 kernel on any x86 machine. I have four machines on my desk at the moment. The workstation is a dual P-III. I suppose I agree that it might be nice if the kernel for that also worked on the embedded 386 board. But it'd also be nice if it worked on the Alpha and the SH boards which are also on my desk. How about putting the whole lot into a single kernel image? It's the logical extension of what's being suggested. No. In the x86 case, it is a question of "do we deliberately restrict this kernel to running only on a Pentium II in order to make it x% faster". My suggestion does not duplicate any code, or (with a few exceptions) include any redundant code for any platform (maths emulation, e.g., would be an exception). Yours duplicates code, rather than just not optimising it as aggressively. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 chosen? Need a way to say it is a cross build, but > > > that shouldn't be too hard. > > > > Why default to incompatibility?! If the user explicitly says "I really do want > > a kernel which only works on this specific machine as it is now, and I want it > > to break otherwise", fine. Don't make it a default! > > I could go along with this. The user, however, had the default break, > and, to my knowledge, there are no tools to diagnose the current (or any > other) machine anywhere in the kernel. Maybe it is time to do such a > tool with exports that the configure programs could use as defaults. My > thought is that the tool could run independently on the target system > (be it local or otherwise) with the results fed back to configure. 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. > (Oops, corollary to the rule that "The squeaking wheel gets the grease." > is "S/he who complains most about the squeaking gets to do the > greasing." I better keep quiet :) I'm still not convinced the wheel IS squeaking - anyone got those benchmarks?? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 > > that shouldn't be too hard. > > Why default to incompatibility?! If the user explicitly says "I really do want > a kernel which only works on this specific machine as it is now, and I want it > to break otherwise", fine. Don't make it a default! I could go along with this. The user, however, had the default break, and, to my knowledge, there are no tools to diagnose the current (or any other) machine anywhere in the kernel. Maybe it is time to do such a tool with exports that the configure programs could use as defaults. My thought is that the tool could run independently on the target system (be it local or otherwise) with the results fed back to configure. (Oops, corollary to the rule that "The squeaking wheel gets the grease." is "S/he who complains most about the squeaking gets to do the greasing." I better keep quiet :) > > BTW: Has anyone benchmarked the different optimizations - i.e. how much > difference does optimizing for a Pentium make when running on a PII? More to > the point, how about optimizing non-exclusively for a Pentium, so the code > still runs on earlier CPUs? > > James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 default to incompatibility?! If the user explicitly says "I really do want a kernel which only works on this specific machine as it is now, and I want it to break otherwise", fine. Don't make it a default! BTW: Has anyone benchmarked the different optimizations - i.e. how much difference does optimizing for a Pentium make when running on a PII? More to the point, how about optimizing non-exclusively for a Pentium, so the code still runs on earlier CPUs? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 write one, as I would hope that most linux users are willing to compile their own kernels... -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 loader after all, > > > > it's hte loader that locates data in memory. If Linux were PE based, > > > > relocation logic would be a snap with this model (like NT). > > > > > > Are you suggesting multiple files of differing alignments packed into > > > a single kernel image, and have the loader select the correct one at > > > runtime ? I really hope I've misinterpreted your intention. > > > > Or more practically, a smart loader than could select a kernel image > > based on arch and auto-detect to load the correct image. I don't really > > think it matters much what mechanism is used. > > > > 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 i386, i586, i686, etc. > > > And this would fit on my 1.4bm floppy so I can boot my hard driveless > firewalling system, correct? Hard disks (20GB) are about $100.00 these days. CD-ROM drives are even cheaper. A smart loader will certainly fit on a floppy. Jeff > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 loader after all, > > > > it's hte loader that locates data in memory. If Linux were PE based, > > > > relocation logic would be a snap with this model (like NT). > > > > > > Are you suggesting multiple files of differing alignments packed into > > > a single kernel image, and have the loader select the correct one at > > > runtime ? I really hope I've misinterpreted your intention. > > > > Or more practically, a smart loader than could select a kernel image > > based on arch and auto-detect to load the correct image. I don't really > > think it matters much what mechanism is used. > > > > 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 i386, i586, i686, etc. > > Sure.. and it will also be able to boot on Alpha/Sparc/PPC:) > > The best is to have the installer (person) to select the primary > archecture from a CD. There will NOT be a single boot loader that will > work for all systems. At best, there will have to be one per CPU family, > but more likely, one per BIOS structure. This is the only thing that can > determine the primary boot. > > The primary boot can then determine which CPU type (starting with the > smallest common CPU), and set flags for a kernel (minimal kernel) load. > During the startup of THAT kernel then the selection of target RPM can > be made that would install a kernel for the specific architetcure. After > a (minimal?) system install, a reboot would be necessary. > > It actually seems like it would be simpler to use the minimal kernel > to rebuild the kernel for the local architecture. MUCH less work. > This still requires a CPU family selection by the person doing the install. > Nothing will get around that. I am hesitant to jump in since hpa is working on something like this. I think I would like to wait and see what he puts out. If he would like for me in my spare time to help him with it, I think I'd love to. Jeff > > - > Jesse I Pollard, II > Email: [EMAIL PROTECTED] > > Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 onerous to make customers > > > recompile kernels all the time and be guinea pigs for arch ports. > > > > 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 kernel is booted, thank you very much. > > Hmm... some mechanism for selecting the appropriate *module* might be nice, > after boot... > > > Plus I'm getting pissed off by how long a boot takes as it stands today... > > Yep: slowing down boottimes is not an attractive idea. > > > > They just want it to boot, and run with the same level of ease of use > > > and stability they get with NT and NetWare and other stuff they are used > > > to. This is an easy choice from where I'm sitting. > > > > Easy: i386. Or i486 (I very much doubt your customers run on less, and this > > should be geneic enough). > > I think there are better options. Jeff could, for example, *optimise* for > Pentium II/III, without using PII specific instructions, in the main kernel, > then have multiple target binaries for modules. > > James. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 make customers > > recompile kernels all the time and be guinea pigs for arch ports. > > 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 kernel is booted, thank you very much. Hmm... some mechanism for selecting the appropriate *module* might be nice, after boot... > Plus I'm getting pissed off by how long a boot takes as it stands today... Yep: slowing down boottimes is not an attractive idea. > > They just want it to boot, and run with the same level of ease of use > > and stability they get with NT and NetWare and other stuff they are used > > to. This is an easy choice from where I'm sitting. > > Easy: i386. Or i486 (I very much doubt your customers run on less, and this > should be geneic enough). I think there are better options. Jeff could, for example, *optimise* for Pentium II/III, without using PII specific instructions, in the main kernel, then have multiple target binaries for modules. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 kernel is booted, thank you very much. > > Plus I'm getting pissed off by how long a boot takes as it stands today... Just for reference I can Boot from Power on to Login prompt in 12 seconds. With Linux. The big change is nuking the BIOS > > They just want it to boot, and run with the same level of ease of use > > and stability they get with NT and NetWare and other stuff they are used > > to. This is an easy choice from where I'm sitting. > > Easy: i386. Or i486 (I very much doubt your customers run on less, and this > should be geneic enough). It's also possible to do a two stage boot. Stage 1 i386 kernel stage 2 the specific kernel for the machine This adds about a second to the whole boot process. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 faster. > > > > > > Except on architectures where 16 byte alignment isn't optimal. > > > > > > > Cache line alignment could be an option in the loader after all, > > > > it's hte loader that locates data in memory. If Linux were PE based, > > > > relocation logic would be a snap with this model (like NT). > > > > > > Are you suggesting multiple files of differing alignments packed into > > > a single kernel image, and have the loader select the correct one at > > > runtime ? I really hope I've misinterpreted your intention. > > > > Or more practically, a smart loader than could select a kernel image > > based on arch and auto-detect to load the correct image. I don't really > > think it matters much what mechanism is used. > > > > 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 i386, i586, i686, etc. > And this would fit on my 1.4bm floppy so I can boot my hard driveless > firewalling system, correct? Your mailer is misattributing people. I didn't say that, my comments were the ones you've attributed to Jeff. regards, davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
> > 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 alignment isn't optimal. > > > > > Cache line alignment could be an option in the loader after all, > > > it's hte loader that locates data in memory. If Linux were PE based, > > > relocation logic would be a snap with this model (like NT). > > > > Are you suggesting multiple files of differing alignments packed into > > a single kernel image, and have the loader select the correct one at > > runtime ? I really hope I've misinterpreted your intention. > > Or more practically, a smart loader than could select a kernel image > based on arch and auto-detect to load the correct image. I don't really > think it matters much what mechanism is used. > > 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 i386, i586, i686, etc. And this would fit on my 1.4bm floppy so I can boot my hard driveless firewalling system, correct? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
- 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 would run a lot faster. > > > > Except on architectures where 16 byte alignment isn't optimal. > > > > > Cache line alignment could be an option in the loader after all, > > > it's hte loader that locates data in memory. If Linux were PE based, > > > relocation logic would be a snap with this model (like NT). > > > > Are you suggesting multiple files of differing alignments packed into > > a single kernel image, and have the loader select the correct one at > > runtime ? I really hope I've misinterpreted your intention. > > Or more practically, a smart loader than could select a kernel image > based on arch and auto-detect to load the correct image. I don't really > think it matters much what mechanism is used. > > 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 i386, i586, i686, etc. Sure.. and it will also be able to boot on Alpha/Sparc/PPC:) The best is to have the installer (person) to select the primary archecture from a CD. There will NOT be a single boot loader that will work for all systems. At best, there will have to be one per CPU family, but more likely, one per BIOS structure. This is the only thing that can determine the primary boot. The primary boot can then determine which CPU type (starting with the smallest common CPU), and set flags for a kernel (minimal kernel) load. During the startup of THAT kernel then the selection of target RPM can be made that would install a kernel for the specific architetcure. After a (minimal?) system install, a reboot would be necessary. It actually seems like it would be simpler to use the minimal kernel to rebuild the kernel for the local architecture. MUCH less work. This still requires a CPU family selection by the person doing the install. Nothing will get around that. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 be guinea pigs for arch ports. 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 kernel is booted, thank you very much. Plus I'm getting pissed off by how long a boot takes as it stands today... > They just want it to boot, and run with the same level of ease of use > and stability they get with NT and NetWare and other stuff they are used > to. This is an easy choice from where I'm sitting. Easy: i386. Or i486 (I very much doubt your customers run on less, and this should be geneic enough). -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 be guinea pigs for arch ports. 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 kernel is booted, thank you very much. Plus I'm getting pissed off by how long a boot takes as it stands today... They just want it to boot, and run with the same level of ease of use and stability they get with NT and NetWare and other stuff they are used to. This is an easy choice from where I'm sitting. Easy: i386. Or i486 (I very much doubt your customers run on less, and this should be geneic enough). -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 faster. Except on architectures where 16 byte alignment isn't optimal. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Are you suggesting multiple files of differing alignments packed into a single kernel image, and have the loader select the correct one at runtime ? I really hope I've misinterpreted your intention. Or more practically, a smart loader than could select a kernel image based on arch and auto-detect to load the correct image. I don't really think it matters much what mechanism is used. 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 i386, i586, i686, etc. And this would fit on my 1.4bm floppy so I can boot my hard driveless firewalling system, correct? Your mailer is misattributing people. I didn't say that, my comments were the ones you've attributed to Jeff. regards, davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 kernel is booted, thank you very much. Plus I'm getting pissed off by how long a boot takes as it stands today... Just for reference I can Boot from Power on to Login prompt in 12 seconds. With Linux. The big change is nuking the BIOS They just want it to boot, and run with the same level of ease of use and stability they get with NT and NetWare and other stuff they are used to. This is an easy choice from where I'm sitting. Easy: i386. Or i486 (I very much doubt your customers run on less, and this should be geneic enough). It's also possible to do a two stage boot. Stage 1 i386 kernel stage 2 the specific kernel for the machine This adds about a second to the whole boot process. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 make customers recompile kernels all the time and be guinea pigs for arch ports. 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 kernel is booted, thank you very much. Hmm... some mechanism for selecting the appropriate *module* might be nice, after boot... Plus I'm getting pissed off by how long a boot takes as it stands today... Yep: slowing down boottimes is not an attractive idea. They just want it to boot, and run with the same level of ease of use and stability they get with NT and NetWare and other stuff they are used to. This is an easy choice from where I'm sitting. Easy: i386. Or i486 (I very much doubt your customers run on less, and this should be geneic enough). I think there are better options. Jeff could, for example, *optimise* for Pentium II/III, without using PII specific instructions, in the main kernel, then have multiple target binaries for modules. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Are you suggesting multiple files of differing alignments packed into a single kernel image, and have the loader select the correct one at runtime ? I really hope I've misinterpreted your intention. Or more practically, a smart loader than could select a kernel image based on arch and auto-detect to load the correct image. I don't really think it matters much what mechanism is used. 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 i386, i586, i686, etc. Sure.. and it will also be able to boot on Alpha/Sparc/PPC:) The best is to have the installer (person) to select the primary archecture from a CD. There will NOT be a single boot loader that will work for all systems. At best, there will have to be one per CPU family, but more likely, one per BIOS structure. This is the only thing that can determine the primary boot. The primary boot can then determine which CPU type (starting with the smallest common CPU), and set flags for a kernel (minimal kernel) load. During the startup of THAT kernel then the selection of target RPM can be made that would install a kernel for the specific architetcure. After a (minimal?) system install, a reboot would be necessary. It actually seems like it would be simpler to use the minimal kernel to rebuild the kernel for the local architecture. MUCH less work. This still requires a CPU family selection by the person doing the install. Nothing will get around that. I am hesitant to jump in since hpa is working on something like this. I think I would like to wait and see what he puts out. If he would like for me in my spare time to help him with it, I think I'd love to. Jeff - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Are you suggesting multiple files of differing alignments packed into a single kernel image, and have the loader select the correct one at runtime ? I really hope I've misinterpreted your intention. Or more practically, a smart loader than could select a kernel image based on arch and auto-detect to load the correct image. I don't really think it matters much what mechanism is used. 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 i386, i586, i686, etc. And this would fit on my 1.4bm floppy so I can boot my hard driveless firewalling system, correct? Hard disks (20GB) are about $100.00 these days. CD-ROM drives are even cheaper. A smart loader will certainly fit on a floppy. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 write one, as I would hope that most linux users are willing to compile their own kernels... -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 default to incompatibility?! If the user explicitly says "I really do want a kernel which only works on this specific machine as it is now, and I want it to break otherwise", fine. Don't make it a default! BTW: Has anyone benchmarked the different optimizations - i.e. how much difference does optimizing for a Pentium make when running on a PII? More to the point, how about optimizing non-exclusively for a Pentium, so the code still runs on earlier CPUs? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 that shouldn't be too hard. Why default to incompatibility?! If the user explicitly says "I really do want a kernel which only works on this specific machine as it is now, and I want it to break otherwise", fine. Don't make it a default! I could go along with this. The user, however, had the default break, and, to my knowledge, there are no tools to diagnose the current (or any other) machine anywhere in the kernel. Maybe it is time to do such a tool with exports that the configure programs could use as defaults. My thought is that the tool could run independently on the target system (be it local or otherwise) with the results fed back to configure. (Oops, corollary to the rule that "The squeaking wheel gets the grease." is "S/he who complains most about the squeaking gets to do the greasing." I better keep quiet :) BTW: Has anyone benchmarked the different optimizations - i.e. how much difference does optimizing for a Pentium make when running on a PII? More to the point, how about optimizing non-exclusively for a Pentium, so the code still runs on earlier CPUs? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 chosen? Need a way to say it is a cross build, but that shouldn't be too hard. Why default to incompatibility?! If the user explicitly says "I really do want a kernel which only works on this specific machine as it is now, and I want it to break otherwise", fine. Don't make it a default! I could go along with this. The user, however, had the default break, and, to my knowledge, there are no tools to diagnose the current (or any other) machine anywhere in the kernel. Maybe it is time to do such a tool with exports that the configure programs could use as defaults. My thought is that the tool could run independently on the target system (be it local or otherwise) with the results fed back to configure. 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. (Oops, corollary to the rule that "The squeaking wheel gets the grease." is "S/he who complains most about the squeaking gets to do the greasing." I better keep quiet :) I'm still not convinced the wheel IS squeaking - anyone got those benchmarks?? James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 architecture. two options:
> > >
> > > 1. extend gcc to support this or rearragne linux into segments based on
> > > code type
> > > 2. Use PE.
> >
> > The kernel isn't going non-ELF. Too painful, for dubious advantages,
> > namely:
> >
> > The current gcc toolchain already supports what you suggest.
> >
> > I understand that some people have even put some thought into a
> > bootloader that dynamically links your kernel on bootup, so this idea
> > isn't new. It's a good idea though.
> >
>
> Yes, I have been working on it on and off for a while ("off" due to
> various professional and personal issues taking higher priority for some
> time...)
Keep truckin' H. Peter, this is something that's needed.
:-)
Jeff
>
> -hpa
>
> --
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 guinea pigs for arch ports. > They just want it to boot, and run with the same level of ease of use > and stability they get with NT and NetWare and other stuff they are used > to. This is an easy choice from where I'm sitting. So you're complaining that as a vendor you have to ship multiple kernels? The point remains the same. The only time I recall recently where a kernel hasn't booted was when the AMD Athlon appeared, and the MTRR code needed fixing. There wasn't a lot anyone could have done, without seeing documentation (which iirc wasn't available at the time). The reason NT & Netware probably loaded fine is that they don't set the MTRRs themselves, but rely on third party utilities to do this for them after they've booted. All other recent cases of non booting that I've seen have been a case of user error miscompiling for a wrong target. As a vendor, you don't worry about this as you ship binary kernels, and $enduser never needs to see a source tree. davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 i386, i586, i686, etc. Jeff, in x86 alone, there are 13 different compile targets (2.4 tree), soon to be more when Cyrix III & Pentium IV get added. Although it doesn't make sense on all of these, it's possible to compile any of them with SMP support too. That's 30 different combinations. Suggesting to put all these into one file isn't a bad idea, it's bordering on insanity. What do you hope to achieve by doing this, apart from the end user not having to choose a custom kernel for their architecture ? Much better to have several kernels built seperately for each arch, and have the user pick which one (or even have the distro installer autodetect) at install time, as SuSE, Red Hat, Mandrake, and several other distros are now doing. Everything all in one may be the way NT does it, but that does not mean it's a good idea. In fact it's anything but a good idea. Please don't try to bring the braindamages of NT to Linux, it just isn't meant to happen. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 go off and give some thought and study and respond > > later after I have a proposal on the best way to do this. In NetWare, > > we had indirections in the code all over the place. NT just make huge > > and fat programs (NTKRNLOS.DLL is absolutely huge). > > I'm glad you realise this. The Netware method you mention above sounds > over complicated for the desired end result, and the NT method just sounds > like a gross hack. > > The current 'compile for the arch you intend to run on' is right now, > the simplest, cleanest way to do this. > > If you manage to pull something off in MANOS or whatever other OS, > to prove all this otherwise (without resorting to ugly hacks like the > above), great for you, I (and I assume others) would like to hear > about it. 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 guinea pigs for arch ports. They just want it to boot, and run with the same level of ease of use and stability they get with NT and NetWare and other stuff they are used to. This is an easy choice from where I'm sitting. Jeff > Davej. > > -- > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Installing kernel 2.4
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 relevance was the one on dynamic optimization techniques, which is what I assume you were referring to. It's interesting stuff, but I think it'd be a cold day in hell before Linus accepts a dynamic recompiler in kernel space. :) regards, davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 alignment isn't optimal. > > > Cache line alignment could be an option in the loader after all, > > it's hte loader that locates data in memory. If Linux were PE based, > > relocation logic would be a snap with this model (like NT). > > Are you suggesting multiple files of differing alignments packed into > a single kernel image, and have the loader select the correct one at > runtime ? I really hope I've misinterpreted your intention. Or more practically, a smart loader than could select a kernel image based on arch and auto-detect to load the correct image. I don't really think it matters much what mechanism is used. 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 i386, i586, i686, etc. Jeff > > regards, > > Davej. > > -- > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 proposal on the best way to do this. In NetWare, > we had indirections in the code all over the place. NT just make huge > and fat programs (NTKRNLOS.DLL is absolutely huge). I'm glad you realise this. The Netware method you mention above sounds over complicated for the desired end result, and the NT method just sounds like a gross hack. The current 'compile for the arch you intend to run on' is right now, the simplest, cleanest way to do this. If you manage to pull something off in MANOS or whatever other OS, to prove all this otherwise (without resorting to ugly hacks like the above), great for you, I (and I assume others) would like to hear about it. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 size. > > ftp.timpanogas.org/manos/manos0817.tar.gz > > Look in the PE loader The last time I looked at your code, I stopped reading after I got to a comment mentioning trade secrets, and intellectual property. > -- Microsoft's PE loader can do this since everything is RVA based. > If you want to take the loader and put it in Linux, be my guest. Why ?? > You can even combine mutiple i86 segments all compiled under different > options (or architectures) and bundle them into a single executable file There is nothing stopping us from doing that now, we just choose not to, as it would result in a ridiculously oversized kernel. Even if the loader threw away the non-used segments, I don't think anyone can justify an on-disk kernel image containing mostly code they never execute. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 loader after all, > it's hte loader that locates data in memory. If Linux were PE based, > relocation logic would be a snap with this model (like NT). Are you suggesting multiple files of differing alignments packed into a single kernel image, and have the loader select the correct one at runtime ? I really hope I've misinterpreted your intention. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Installing kernel 2.4
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. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > 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 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 could be dynamically detected. > > 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 size. > > regards, > > Davej. > > -- > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > | SuSE Labs > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Installing kernel 2.4
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:[EMAIL 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, > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 rearragne linux into segments based on
> > code type
> > 2. Use PE.
>
> The kernel isn't going non-ELF. Too painful, for dubious advantages,
> namely:
>
> The current gcc toolchain already supports what you suggest.
>
> I understand that some people have even put some thought into a
> bootloader that dynamically links your kernel on bootup, so this idea
> isn't new. It's a good idea though.
>
Yes, I have been working on it on and off for a while ("off" due to
various professional and personal issues taking higher priority for some
time...)
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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. Alan, if ELF can do this now, it would be good idea to do this with the mutiple images. Sounds like it's just a link option and a few more smarts in the lilo and boot loader to make it work. 8) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
> 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" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
> 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 "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 am building the RPM for Ute Linux with 2.4.0-10 and right now, I have to do what RedHat does, and create the /config "directory from hell" with two dosen .config files and create multiple RPMs for each kernel (i.e. i586, .i686). It's too convoluted and customers hate it. 8) Jeff > > -- > Jeff Garzik | "When I do this, my computer freezes." > Building 1024 | -user > MandrakeSoft| "Don't do that." > | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 instructions, > > etc. All of this on x86 could be dynamically detected. > > Detection isnt the issue, its optimisations. Our 386 kernel build is the > detect all run on any one. > > > mov sp, bx > > mov CPU_TYPE, 3 ; 80386 detected > > jz end_get_cpuid > > This is wrong btw. You don;t check for Cyrix with CPUID disabled or > the NexGen or pre CPUID Cyrix... Thanks Alan, I'll fix immediately. Jeff > > > check_CMPXCHG8B: > > mov ax, word ptr ds:FEATURE_FLAGS > > and ax, CMPXCHG8B_FLAG > > jz check_4MB_paging > > This needs a few other bits of interesting checking for non intel chips I'll grab the code in linux and port. 8) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 CPU type, feature flags, special instructions, > etc. All of this on x86 could be dynamically detected. Detection isnt the issue, its optimisations. Our 386 kernel build is the detect all run on any one. > mov sp, bx > mov CPU_TYPE, 3 ; 80386 detected > jz end_get_cpuid This is wrong btw. You don;t check for Cyrix with CPUID disabled or the NexGen or pre CPUID Cyrix... > check_CMPXCHG8B: > mov ax, word ptr ds:FEATURE_FLAGS > and ax, CMPXCHG8B_FLAG > jz check_4MB_paging This needs a few other bits of interesting checking for non intel chips - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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".
>
> The bootloader would then load the kernel, or could give an informative
> diagnostic.
>
The PE model uses flags to identify CPU type and capbilities and create
a table in the RVA section header that describes all the segments, i.e.
#define IMAGE_SIZEOF_FILE_HEADER20
#define IMAGE_FILE_MACHINE_UNKNOWN 0
#define IMAGE_FILE_MACHINE_I860 0x14d
#define IMAGE_FILE_MACHINE_I386 0x14c
#define IMAGE_FILE_MACHINE_R30000x162
#define IMAGE_FILE_MACHINE_R40000x166
#define IMAGE_FILE_MACHINE_R1 0x168
#define IMAGE_FILE_MACHINE_ALPHA0x184
#define IMAGE_FILE_MACHINE_POWERPC 0x1F0
typedef struct _IMAGE_DATA_DIRECTORY
{
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY;
#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16
/* Optional coff header - used by NT to provide additional information.
*/
typedef struct _IMAGE_OPTIONAL_HEADER
{
/*
* Standard fields.
*/
WORDMagic;
BYTEMajorLinkerVersion;
BYTEMinorLinkerVersion;
DWORD SizeOfCode;
DWORD SizeOfInitializedData;
DWORD SizeOfUninitializedData;
DWORD AddressOfEntryPoint;
DWORD BaseOfCode;
DWORD BaseOfData;
/*
* NT additional fields.
*/
DWORD ImageBase;
DWORD SectionAlignment;
DWORD FileAlignment;
WORDMajorOperatingSystemVersion;
WORDMinorOperatingSystemVersion;
WORDMajorImageVersion;
WORDMinorImageVersion;
WORDMajorSubsystemVersion;
WORDMinorSubsystemVersion;
DWORD Reserved1;
DWORD SizeOfImage;
DWORD SizeOfHeaders;
DWORD CheckSum;
WORDSubsystem;
WORDDllCharacteristics;
DWORD SizeOfStackReserve;
DWORD SizeOfStackCommit;
DWORD SizeOfHeapReserve;
DWORD SizeOfHeapCommit;
DWORD LoaderFlags;
DWORD NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER,*PIMAGE_OPTIONAL_HEADER;
/* These are indexes into the DataDirectory array */
#define IMAGE_FILE_EXPORT_DIRECTORY 0
#define IMAGE_FILE_IMPORT_DIRECTORY 1
#define IMAGE_FILE_RESOURCE_DIRECTORY 2
#define IMAGE_FILE_EXCEPTION_DIRECTORY 3
#define IMAGE_FILE_SECURITY_DIRECTORY 4
#define IMAGE_FILE_BASE_RELOCATION_TABLE5
#define IMAGE_FILE_DEBUG_DIRECTORY 6
#define IMAGE_FILE_DESCRIPTION_STRING 7
#define IMAGE_FILE_MACHINE_VALUE8 /* Mips */
#define IMAGE_FILE_THREAD_LOCAL_STORAGE 9
#define IMAGE_FILE_CALLBACK_DIRECTORY 10
/* Directory Entries, indices into the DataDirectory array */
#define IMAGE_DIRECTORY_ENTRY_EXPORT0
#define IMAGE_DIRECTORY_ENTRY_IMPORT1
#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3
#define IMAGE_DIRECTORY_ENTRY_SECURITY 4
#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5
#define IMAGE_DIRECTORY_ENTRY_DEBUG 6
#define IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 /* (MIPS GP) */
#define IMAGE_DIRECTORY_ENTRY_TLS 9
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11
#define IMAGE_DIRECTORY_ENTRY_IAT 12 /* Import Address Table */
/* Subsystem Values */
#define IMAGE_SUBSYSTEM_UNKNOWN 0
#define IMAGE_SUBSYSTEM_NATIVE 1
#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2 /* Windows GUI subsystem */
#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3 /* Windows character subsystem*/
#define IMAGE_SUBSYSTEM_OS2_CUI 5
#define IMAGE_SUBSYSTEM_POSIX_CUI 7
typedef struct _IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER OptionalHeader;
} IMAGE_NT_HEADERS,*PIMAGE_NT_HEADERS;
/* Section header format */
#define IMAGE_SIZEOF_SHORT_NAME 8
typedef struct _IMAGE_SECTION_HEADER {
BYTEName[IMAGE_SIZEOF_SHORT_NAME];
union {
DWORD PhysicalAddress;
DWORD VirtualSize;
} Misc;
DWORD VirtualAddress;
DWORD SizeOfRawData;
DWORD PointerToRawData;
DWORD PointerToRelocations;
DWORD PointerToLinenumbers;
WORDNumberOfRelocations;
WORDNumberOfLinenumbers;
DWORD Characteristics;
}
Re: Installing kernel 2.4
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 kernel, or could give an informative diagnostic. David At 06:59 PM 11/7/00, Jeff Garzik wrote: >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 > > uncompress and to detect the cpu with lower optimizations and then abort > > with an error message? > > > > "Error: Kernel needs a PIII" sounds much better than just stoping dead. > >I agree... maybe we can solve this simply by giving the CPU detection >module the -march=i386 flag hardcoded, or editing the bootstrap, or >something like that... > > Jeff David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] 514 W. Keech Ave. www.osagesoftware.com Ann Arbor, MI 48103 voice: 734.821.8800fax: 734.821.8800 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 rearragne linux into segments based on > > code type > > 2. Use PE. > > 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 Jeff > The current gcc toolchain already supports what you suggest. > > I understand that some people have even put some thought into a > bootloader that dynamically links your kernel on bootup, so this idea > isn't new. It's a good idea though. > > Jeff > > -- > Jeff Garzik | "When I do this, my computer freezes." > Building 1024 | -user > MandrakeSoft| "Don't do that." > | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
David Lang wrote: > > Jeff, the kernel image is already pretty large. if you try and take what > are basicly independant kernel images and put them in one file you will > very quickly endup with something that is to large to use. > > As an example a kenel for a boot floppy needs to be <1.4MB compressed, > it's not uncommon for it to be >800K compressed as it is, how do you fit > even two of these on a disk. > > 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 proposal on the best way to do this. In NetWare, we had indirections in the code all over the place. NT just make huge and fat programs (NTKRNLOS.DLL is absolutely huge). 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]> > > Subject: Re: Installing kernel 2.4 > > > > > > > > "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 type, feature flags, special instructions, > > > > > etc. All of this on x86 could be dynamically detected. > > > > > > > > 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 size. > > > > ftp.timpanogas.org/manos/manos0817.tar.gz > > > > Look in the PE loader -- Microsoft's PE loader can do this since > > everything is RVA based. If you want to take the loader and put it in > > Linux, be my guest. You can even combine mutiple i86 segments all > > compiled under different options (or architectures) and bundle them into > > a single executable file -- not somthing gcc can do today -- even with > > DLL. This code is almost identical to the PE loader used in NT -- with > > one exception, I omit the fs:_THREAD_DLS startup code... > > > > 8) > > > > Jeff > > > > > > > > > > If the compiler always aligned all functions and data on 16 byte > > > boundries (NetWare) > > > for all i386 code, it would run a lot faster. Cache line alignment > > > could be an option in the loader after all, it's hte loader that > > > locates data in memory. If Linux were PE based, relocation logic would > > > be a snap with this model (like NT). > > > > > > Jeff > > > > > > > > > > > regards, > > > > > > > > Davej. > > > > > > > > -- > > > > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > > > > | SuSE Labs > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 type > 2. Use PE. The kernel isn't going non-ELF. Too painful, for dubious advantages, namely: The current gcc toolchain already supports what you suggest. I understand that some people have even put some thought into a bootloader that dynamically links your kernel on bootup, so this idea isn't new. It's a good idea though. Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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, note use of "...align...": > /usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing > -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 > -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o extable.o > extable.c > > 2.4.x, note "preferred-stack-boundary" and generated asm code... > gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include > /spare/cvs/linux_2_4/include/linux/modversions.h -c -o emd.o emd.c > > Jeff > > -- > Jeff Garzik | "When I do this, my computer freezes." > Building 1024 | -user > MandrakeSoft| "Don't do that." > | -level 1 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
Jeff, the kernel image is already pretty large. if you try and take what are basicly independant kernel images and put them in one file you will very quickly endup with something that is to large to use. As an example a kenel for a boot floppy needs to be <1.4MB compressed, it's not uncommon for it to be >800K compressed as it is, how do you fit even two of these on a disk. 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. 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: Installing kernel 2.4 > > > > "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 type, feature flags, special instructions, > > > > etc. All of this on x86 could be dynamically detected. > > > > > > 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 size. > > ftp.timpanogas.org/manos/manos0817.tar.gz > > Look in the PE loader -- Microsoft's PE loader can do this since > everything is RVA based. If you want to take the loader and put it in > Linux, be my guest. You can even combine mutiple i86 segments all > compiled under different options (or architectures) and bundle them into > a single executable file -- not somthing gcc can do today -- even with > DLL. This code is almost identical to the PE loader used in NT -- with > one exception, I omit the fs:_THREAD_DLS startup code... > > 8) > > Jeff > > > > > > If the compiler always aligned all functions and data on 16 byte > > boundries (NetWare) > > for all i386 code, it would run a lot faster. Cache line alignment > > could be an option in the loader after all, it's hte loader that > > locates data in memory. If Linux were PE based, relocation logic would > > be a snap with this model (like NT). > > > > Jeff > > > > > > > > regards, > > > > > > Davej. > > > > > > -- > > > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > > > | SuSE Labs > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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, special instructions, > > etc. All of this on x86 could be dynamically detected. > > Jeff, I think you miss the point that 100% dynamic detection comes with > a penalty over the current system. > > Using CONFIG_M586 enables us to compile with Pentium-specific > instructions, and eliminate any code specific to 386's or 486's. This > includes inlining Pentium-specific code into drivers and the core kernel > where possible, for the maximum possible performance. Your scheme > doesn't work because of all the inlined code, nor does it support > maximum performance code on all processors without massive code bloat... > > You do bring up a good point though. Users compile their own kernels to > get the advantages I describe above. Vendors, on the other hand, must > compile one-size-fits-all generic kernels. Your expertise and > assistance would definitely benefit this case. > 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 type 2. Use PE. Jeff > One change I would like to make in 2.5.x along these lines -- the Alpha > AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all > processors/machines -- or CONFIG_ALPHA_$MYMACHINE. It would be nice to > follow that model for x86 too. Currently, when I select CONFIG_M586, I > get code for 686, etc. There is no way to simply say "Pentium and > nothing else". > > Jeff > > -- > Jeff Garzik | "When I do this, my computer freezes." > Building 1024 | -user > MandrakeSoft| "Don't do that." > | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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, note use of "...align...": /usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o extable.o extable.c 2.4.x, note "preferred-stack-boundary" and generated asm code... gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /spare/cvs/linux_2_4/include/linux/modversions.h -c -o emd.o emd.c Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 > uncompress and to detect the cpu with lower optimizations and then abort > with an error message? > > "Error: Kernel needs a PIII" sounds much better than just stoping dead. I agree... maybe we can solve this simply by giving the CPU detection module the -march=i386 flag hardcoded, or editing the bootstrap, or something like that... Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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. All of this on x86 could be dynamically detected. Jeff, I think you miss the point that 100% dynamic detection comes with a penalty over the current system. Using CONFIG_M586 enables us to compile with Pentium-specific instructions, and eliminate any code specific to 386's or 486's. This includes inlining Pentium-specific code into drivers and the core kernel where possible, for the maximum possible performance. Your scheme doesn't work because of all the inlined code, nor does it support maximum performance code on all processors without massive code bloat... You do bring up a good point though. Users compile their own kernels to get the advantages I describe above. Vendors, on the other hand, must compile one-size-fits-all generic kernels. Your expertise and assistance would definitely benefit this case. One change I would like to make in 2.5.x along these lines -- the Alpha AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all processors/machines -- or CONFIG_ALPHA_$MYMACHINE. It would be nice to follow that model for x86 too. Currently, when I select CONFIG_M586, I get code for 686, etc. There is no way to simply say "Pentium and nothing else". Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 cpu with lower optimizations and then abort with an error message? "Error: Kernel needs a PIII" sounds much better than just stoping dead. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 type, feature flags, special instructions, > > > etc. All of this on x86 could be dynamically detected. > > > > 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 size. ftp.timpanogas.org/manos/manos0817.tar.gz Look in the PE loader -- Microsoft's PE loader can do this since everything is RVA based. If you want to take the loader and put it in Linux, be my guest. You can even combine mutiple i86 segments all compiled under different options (or architectures) and bundle them into a single executable file -- not somthing gcc can do today -- even with DLL. This code is almost identical to the PE loader used in NT -- with one exception, I omit the fs:_THREAD_DLS startup code... 8) Jeff > > If the compiler always aligned all functions and data on 16 byte > boundries (NetWare) > for all i386 code, it would run a lot faster. Cache line alignment > could be an option in the loader after all, it's hte loader that > locates data in memory. If Linux were PE based, relocation logic would > be a snap with this model (like NT). > > Jeff > > > > > regards, > > > > Davej. > > > > -- > > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > > | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
David Lang wrote: > > 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. The macros would be a problem. Some of the options, like MTRR, should be auto-detected. Jeff > > 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 > > On Tue, 7 Nov 2000, Jeff V. 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 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 CPU type, feature flags, special instructions, > > etc. All of this on x86 could be dynamically detected. > > > > :-) > > > > ;* > > ; > > ; check current processor type and state > > ; > > ;* > > > > public DetectProcessorInformation > > DetectProcessorInformation proc near > > > > mov ax, cs > > mov ds, ax > > mov es, ax > > > > pushf > > call get_cpuid > > call get_fpuid > > call print > > popf > > ret > > > > DetectProcessorInformation endp > > > > get_cpuid proc near > > > > check_8086: > > > > pushf > > pop ax > > mov cx, ax > > and ax, 0fffh > > push ax > > popf > > pushf > > pop ax > > and ax, 0f000h > > cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 > > mov CPU_TYPE, 0 ; 8086 detected > > jeend_get_cpuid > > > > check_80286: > > orcx, 0f000h > > push cx > > popf > > pushf > > pop ax > > and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in > > real mode > > mov CPU_TYPE, 2 ; 80286 processor > > jzend_get_cpuid > > > > check_80386: > > mov bx, sp > > and sp, not 3 > > OPND32 > > pushf > > OPND32 > > pop ax > > OPND32 > > mov cx, ax > > OPND32 35h, 4h > > OPND32 > > push ax > > OPND32 > > popf > > OPND32 > > pushf > > OPND32 > > pop ax > > OPND32 > > xor ax, cx ; AC bit won't toggle, 80386 detected > > mov sp, bx > > mov CPU_TYPE, 3 ; 80386 detected > > jz end_get_cpuid > > > > and sp, not 3 > > OPND32 > > push cx > > OPND32 > > popf > > mov sp, bx ; restore stack > > > > > > check_80486: > > mov CPU_TYPE, 4 ; default to 80486 > > > > OPND32 > > mov ax, cx > > OPND32 35h, 20h ; xor ID bit > > OPND32 > > push ax > > OPND32 > > popf > > OPND32 > > pushf > > OPND32 > > pop ax > > OPND32 > > xor ax, cx ; cant toggle ID bit > > je end_get_cpuid > > > > > > check_vendor: > > mov ID_FLAG, 1 > > OPND32 > > xor ax, ax > > CPUID > > OPND32 > > mov word ptr VENDOR_ID, bx > > OPND32 > > mov word ptr VENDOR_ID[+4], dx > > OPND32 > > mov word ptr VENDOR_ID[+8], cx > > mov si, offset VENDOR_ID > > mov di, offset intel_id > > mov cx, length intel_id > > > > co
Re: Installing kernel 2.4
[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 instructions, > > etc. All of this on x86 could be dynamically detected. > > 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 size. If the compiler always aligned all functions and data on 16 byte boundries (NetWare) for all i386 code, it would run a lot faster. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Jeff > > regards, > > Davej. > > -- > | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej > | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 On Tue, 7 Nov 2000, Jeff V. 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 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 CPU type, feature flags, special instructions, > etc. All of this on x86 could be dynamically detected. > > :-) > > ;* > ; > ; check current processor type and state > ; > ;* > > public DetectProcessorInformation > DetectProcessorInformation proc near > > mov ax, cs > mov ds, ax > mov es, ax > > pushf > call get_cpuid > call get_fpuid > call print > popf > ret > > DetectProcessorInformation endp > > get_cpuid proc near > > check_8086: > > pushf > pop ax > mov cx, ax > and ax, 0fffh > push ax > popf > pushf > pop ax > and ax, 0f000h > cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 > mov CPU_TYPE, 0 ; 8086 detected > jeend_get_cpuid > > check_80286: > orcx, 0f000h > push cx > popf > pushf > pop ax > and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in > real mode > mov CPU_TYPE, 2 ; 80286 processor > jzend_get_cpuid > > check_80386: > mov bx, sp > and sp, not 3 > OPND32 > pushf > OPND32 > pop ax > OPND32 > mov cx, ax > OPND32 35h, 4h > OPND32 > push ax > OPND32 > popf > OPND32 > pushf > OPND32 > pop ax > OPND32 > xor ax, cx ; AC bit won't toggle, 80386 detected > mov sp, bx > mov CPU_TYPE, 3 ; 80386 detected > jz end_get_cpuid > > and sp, not 3 > OPND32 > push cx > OPND32 > popf > mov sp, bx ; restore stack > > > check_80486: > mov CPU_TYPE, 4 ; default to 80486 > > OPND32 > mov ax, cx > OPND32 35h, 20h ; xor ID bit > OPND32 > push ax > OPND32 > popf > OPND32 > pushf > OPND32 > pop ax > OPND32 > xor ax, cx ; cant toggle ID bit > je end_get_cpuid > > > check_vendor: > mov ID_FLAG, 1 > OPND32 > xor ax, ax > CPUID > OPND32 > mov word ptr VENDOR_ID, bx > OPND32 > mov word ptr VENDOR_ID[+4], dx > OPND32 > mov word ptr VENDOR_ID[+8], cx > mov si, offset VENDOR_ID > mov di, offset intel_id > mov cx, length intel_id > > compare: > repecmpsb > or cx, cx > jnz end_get_cpuid > > intel_processor: > mov INTEL_PROC, 1 > > cpuid_data: > OPND32 > cmp ax, 1 > > jl end_get_cpuid > OPND32 > xor ax, ax > OPND32 > inc ax > CPUID > mov byte ptr ds:STEPPING, al > and STEPPING, STEPPING_MASK > > and al, MODEL_MASK > shr al, MODEL_SHIFT > mov byte ptr ds:CPU_MODEL, al > > and ax, FAMILY_MASK > shr ax, FAMILY_SHIFT > mov byte ptr ds:CPU_TYPE, al > > mov dword ptr FEATURE_FLAGS, edx > > end_get_cpuid: > ret > > get_cpuid endp > > > get_fpuid proc near > > fninit > mov word ptr ds:FP_STATUS, 5a5ah >
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 CPU type, feature flags, special instructions, > etc. All of this on x86 could be dynamically detected. 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 size. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 CPU type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. :-) ;* ; ; check current processor type and state ; ;* public DetectProcessorInformation DetectProcessorInformation proc near mov ax, cs mov ds, ax mov es, ax pushf call get_cpuid call get_fpuid call print popf ret DetectProcessorInformation endp get_cpuid proc near check_8086: pushf pop ax mov cx, ax and ax, 0fffh push ax popf pushf pop ax and ax, 0f000h cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 mov CPU_TYPE, 0 ; 8086 detected jeend_get_cpuid check_80286: orcx, 0f000h push cx popf pushf pop ax and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in real mode mov CPU_TYPE, 2 ; 80286 processor jzend_get_cpuid check_80386: mov bx, sp and sp, not 3 OPND32 pushf OPND32 pop ax OPND32 mov cx, ax OPND32 35h, 4h OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; AC bit won't toggle, 80386 detected mov sp, bx mov CPU_TYPE, 3 ; 80386 detected jz end_get_cpuid and sp, not 3 OPND32 push cx OPND32 popf mov sp, bx ; restore stack check_80486: mov CPU_TYPE, 4 ; default to 80486 OPND32 mov ax, cx OPND32 35h, 20h ; xor ID bit OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; cant toggle ID bit je end_get_cpuid check_vendor: mov ID_FLAG, 1 OPND32 xor ax, ax CPUID OPND32 mov word ptr VENDOR_ID, bx OPND32 mov word ptr VENDOR_ID[+4], dx OPND32 mov word ptr VENDOR_ID[+8], cx mov si, offset VENDOR_ID mov di, offset intel_id mov cx, length intel_id compare: repecmpsb or cx, cx jnz end_get_cpuid intel_processor: mov INTEL_PROC, 1 cpuid_data: OPND32 cmp ax, 1 jl end_get_cpuid OPND32 xor ax, ax OPND32 inc ax CPUID mov byte ptr ds:STEPPING, al and STEPPING, STEPPING_MASK and al, MODEL_MASK shr al, MODEL_SHIFT mov byte ptr ds:CPU_MODEL, al and ax, FAMILY_MASK shr ax, FAMILY_SHIFT mov byte ptr ds:CPU_TYPE, al mov dword ptr FEATURE_FLAGS, edx end_get_cpuid: ret get_cpuid endp get_fpuid proc near fninit mov word ptr ds:FP_STATUS, 5a5ah fnstsw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS cmp al, 0 mov FPU_TYPE, 0 jne end_get_fpuid check_control_word: fnstcw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS and ax, 103fh cmp ax, 3fh mov FPU_TYPE, 0 jne end_get_fpuid mov FPU_TYPE, 1 check_infinity: cmp CPU_TYPE, 3 jne end_get_fpuid fld1 fldz fdiv fld st fchs fcompp fstswword ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS mov FPU_TYPE, 2 sahf jz end_get_fpuid mov FPU_TYPE, 3 end_get_fpuid: ret get_fpuid endp print proc near cmp ID_FLAG, 1 je print_cpuid_data if (VERBOSE) mov dx, offset id_msg call OutputMessage endif print_86: cmp CPU_TYPE, 0 jne print_286 if (VERBOSE) mov dx, offset c8086 call OutputMessage endif cmp FPU_TYPE, 0 je end_print if (VERBOSE) mov dx, offset fp_8087 call OutputMessage endif jmp end_print print_286: cmp CPU_TYPE, 2 jne print_386 if (VERBOSE) mov dx, offset c286 call OutputMessage endif cmp FPU_TYPE, 0 je end_print if (VERBOSE) mov dx, offset fp_80287 call OutputMessage endif jmp end_print print_386: cmp CPU_TYPE, 3 jne print_486 if (VERBOSE) mov dx, offset c386 call OutputMessage endif cmp FPU_TYPE, 0 je end_print cmp FPU_TYPE, 2 jne print_387 if (VERBOSE) mov dx, offset fp_80287 call OutputMessage endif jmp end_print print_387: if (VERBOSE) mov dx, offset fp_80387 call OutputMessage endif jmp end_print
Re: Installing kernel 2.4
"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 booting! It should probably default to something safe like 386 though... jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 including the workarounds for ancient hardware. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
I don't know about you, but I like having the option to cut out code from my kernel that will never get used for a particular cpu arch.;o) Or was that just a troll ;o) - Forwarded by Bruce Holzrichter/US/Infinium Software on 11/07/2000 05:46 PM - "Jeff V. Merkey" <[EMAIL PROTECTED]>To: Martin Josefsson Sent by:<[EMAIL PROTECTED]> linux-kernel-owner@vger.cc: Tigran Aivazian kernel.org <[EMAIL PROTECTED]>, Anil kumar <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 11/07/2000 05:32 PM Subject: Re: Installing kernel 2.4 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 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 test11-pre1 > > (or at least test10) was available. So, redo everything you have done with > > test11-pre1 and if you still cannot boot then send a message to this list > > with details like your CPUs, motherboard etc. etc. > > Have you chosen the right cpu type in the configuration? > > /Martin > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 worry about what is it running on, just prints the name... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 test11-pre1 > > (or at least test10) was available. So, redo everything you have done with > > test11-pre1 and if you still cannot boot then send a message to this list > > with details like your CPUs, motherboard etc. etc. > > Have you chosen the right cpu type in the configuration? > > /Martin > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 serious mistake you did was using test9 kernel when test11-pre1 > (or at least test10) was available. So, redo everything you have done with > test11-pre1 and if you still cannot boot then send a message to this list > with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 > redhat > #mv linux linux-2.4.0-test9 > #ln -s linux-2.4.0-test9 linux > > #ls >linux->linux-2.4.0-test9 >linux-2.4.0-test9 >redhat > > #cd /usr/src/linux > #make xconfig > I just save & exit without changing the > configuration. > #make dep > #make clean > #make bzImage > #make modules > #make modules_install > > I find that System.map is mapped to 2.4.0, ie.. new > System-2.4.0-test9.map is created > > #cd /boot > #ls > #vmlinuz->vmlinuz-2.4.0-test9 > #cd /usr/src/linux/arch/i386/boot > #cp bzImage /boot/vmlinuz > > #vi /etc/lilo.conf > changed image from image = /boot/vmlinuz-2.2.16-22 How about making this line match the name of the copied kernel (you copied it as /boot/vmlinuz so thi should be image = /boot/vmlinuz Jeff > to > image = /boot/vmlinuz-2.4.0-test9 > > #lilo >linux > dos > > when I boot linux > > 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 > > with regards, > Anil > > __ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one Place. > http://shopping.yahoo.com/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 redhat #mv linux linux-2.4.0-test9 #ln -s linux-2.4.0-test9 linux #ls linux-linux-2.4.0-test9 linux-2.4.0-test9 redhat #cd /usr/src/linux #make xconfig I just save exit without changing the configuration. #make dep #make clean #make bzImage #make modules #make modules_install I find that System.map is mapped to 2.4.0, ie.. new System-2.4.0-test9.map is created #cd /boot #ls #vmlinuz-vmlinuz-2.4.0-test9 #cd /usr/src/linux/arch/i386/boot #cp bzImage /boot/vmlinuz #vi /etc/lilo.conf changed image from image = /boot/vmlinuz-2.2.16-22 How about making this line match the name of the copied kernel (you copied it as /boot/vmlinuz so thi should be image = /boot/vmlinuz Jeff to image = /boot/vmlinuz-2.4.0-test9 #lilo linux dos when I boot linux 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 with regards, Anil __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 serious mistake you did was using test9 kernel when test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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 test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 worry about what is it running on, just prints the name... -- Juan Antonio Magallon Lacarta # cd /pub mailto:[EMAIL PROTECTED] # more beer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 including the workarounds for ancient hardware. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
I don't know about you, but I like having the option to cut out code from my kernel that will never get used for a particular cpu arch.;o) Or was that just a troll ;o) - Forwarded by Bruce Holzrichter/US/Infinium Software on 11/07/2000 05:46 PM - "Jeff V. Merkey" [EMAIL PROTECTED]To: Martin Josefsson Sent by:[EMAIL PROTECTED] linux-kernel-owner@vger.cc: Tigran Aivazian kernel.org [EMAIL PROTECTED], Anil kumar [EMAIL PROTECTED], [EMAIL PROTECTED] 11/07/2000 05:32 PM Subject: Re: Installing kernel 2.4 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 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 test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 booting! It should probably default to something safe like 386 though... jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 CPU type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. :-) ;* ; ; check current processor type and state ; ;* public DetectProcessorInformation DetectProcessorInformation proc near mov ax, cs mov ds, ax mov es, ax pushf call get_cpuid call get_fpuid call print popf ret DetectProcessorInformation endp get_cpuid proc near check_8086: pushf pop ax mov cx, ax and ax, 0fffh push ax popf pushf pop ax and ax, 0f000h cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 mov CPU_TYPE, 0 ; 8086 detected jeend_get_cpuid check_80286: orcx, 0f000h push cx popf pushf pop ax and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in real mode mov CPU_TYPE, 2 ; 80286 processor jzend_get_cpuid check_80386: mov bx, sp and sp, not 3 OPND32 pushf OPND32 pop ax OPND32 mov cx, ax OPND32 35h, 4h OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; AC bit won't toggle, 80386 detected mov sp, bx mov CPU_TYPE, 3 ; 80386 detected jz end_get_cpuid and sp, not 3 OPND32 push cx OPND32 popf mov sp, bx ; restore stack check_80486: mov CPU_TYPE, 4 ; default to 80486 OPND32 mov ax, cx OPND32 35h, 20h ; xor ID bit OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; cant toggle ID bit je end_get_cpuid check_vendor: mov ID_FLAG, 1 OPND32 xor ax, ax CPUID OPND32 mov word ptr VENDOR_ID, bx OPND32 mov word ptr VENDOR_ID[+4], dx OPND32 mov word ptr VENDOR_ID[+8], cx mov si, offset VENDOR_ID mov di, offset intel_id mov cx, length intel_id compare: repecmpsb or cx, cx jnz end_get_cpuid intel_processor: mov INTEL_PROC, 1 cpuid_data: OPND32 cmp ax, 1 jl end_get_cpuid OPND32 xor ax, ax OPND32 inc ax CPUID mov byte ptr ds:STEPPING, al and STEPPING, STEPPING_MASK and al, MODEL_MASK shr al, MODEL_SHIFT mov byte ptr ds:CPU_MODEL, al and ax, FAMILY_MASK shr ax, FAMILY_SHIFT mov byte ptr ds:CPU_TYPE, al mov dword ptr FEATURE_FLAGS, edx end_get_cpuid: ret get_cpuid endp get_fpuid proc near fninit mov word ptr ds:FP_STATUS, 5a5ah fnstsw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS cmp al, 0 mov FPU_TYPE, 0 jne end_get_fpuid check_control_word: fnstcw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS and ax, 103fh cmp ax, 3fh mov FPU_TYPE, 0 jne end_get_fpuid mov FPU_TYPE, 1 check_infinity: cmp CPU_TYPE, 3 jne end_get_fpuid fld1 fldz fdiv fld st fchs fcompp fstswword ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS mov FPU_TYPE, 2 sahf jz end_get_fpuid mov FPU_TYPE, 3 end_get_fpuid: ret get_fpuid endp print proc near cmp ID_FLAG, 1 je print_cpuid_data if (VERBOSE) mov dx, offset id_msg call OutputMessage endif print_86: cmp CPU_TYPE, 0 jne print_286 if (VERBOSE) mov dx, offset c8086 call OutputMessage endif cmp FPU_TYPE, 0 je end_print if (VERBOSE) mov dx, offset fp_8087 call OutputMessage endif jmp end_print print_286: cmp CPU_TYPE, 2 jne print_386 if (VERBOSE) mov dx, offset c286 call OutputMessage endif cmp FPU_TYPE, 0 je end_print if (VERBOSE) mov dx, offset fp_80287 call OutputMessage endif jmp end_print print_386: cmp CPU_TYPE, 3 jne print_486 if (VERBOSE) mov dx, offset c386 call OutputMessage endif cmp FPU_TYPE, 0 je end_print cmp FPU_TYPE, 2 jne print_387 if (VERBOSE) mov dx, offset fp_80287 call OutputMessage endif jmp end_print print_387: if (VERBOSE) mov dx, offset fp_80387 call OutputMessage endif jmp end_print
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 CPU type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. 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 size. regards, Davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 On Tue, 7 Nov 2000, Jeff V. 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 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 CPU type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. :-) ;* ; ; check current processor type and state ; ;* public DetectProcessorInformation DetectProcessorInformation proc near mov ax, cs mov ds, ax mov es, ax pushf call get_cpuid call get_fpuid call print popf ret DetectProcessorInformation endp get_cpuid proc near check_8086: pushf pop ax mov cx, ax and ax, 0fffh push ax popf pushf pop ax and ax, 0f000h cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 mov CPU_TYPE, 0 ; 8086 detected jeend_get_cpuid check_80286: orcx, 0f000h push cx popf pushf pop ax and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in real mode mov CPU_TYPE, 2 ; 80286 processor jzend_get_cpuid check_80386: mov bx, sp and sp, not 3 OPND32 pushf OPND32 pop ax OPND32 mov cx, ax OPND32 35h, 4h OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; AC bit won't toggle, 80386 detected mov sp, bx mov CPU_TYPE, 3 ; 80386 detected jz end_get_cpuid and sp, not 3 OPND32 push cx OPND32 popf mov sp, bx ; restore stack check_80486: mov CPU_TYPE, 4 ; default to 80486 OPND32 mov ax, cx OPND32 35h, 20h ; xor ID bit OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; cant toggle ID bit je end_get_cpuid check_vendor: mov ID_FLAG, 1 OPND32 xor ax, ax CPUID OPND32 mov word ptr VENDOR_ID, bx OPND32 mov word ptr VENDOR_ID[+4], dx OPND32 mov word ptr VENDOR_ID[+8], cx mov si, offset VENDOR_ID mov di, offset intel_id mov cx, length intel_id compare: repecmpsb or cx, cx jnz end_get_cpuid intel_processor: mov INTEL_PROC, 1 cpuid_data: OPND32 cmp ax, 1 jl end_get_cpuid OPND32 xor ax, ax OPND32 inc ax CPUID mov byte ptr ds:STEPPING, al and STEPPING, STEPPING_MASK and al, MODEL_MASK shr al, MODEL_SHIFT mov byte ptr ds:CPU_MODEL, al and ax, FAMILY_MASK shr ax, FAMILY_SHIFT mov byte ptr ds:CPU_TYPE, al mov dword ptr FEATURE_FLAGS, edx end_get_cpuid: ret get_cpuid endp get_fpuid proc near fninit mov word ptr ds:FP_STATUS, 5a5ah fnstsw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS cmp al, 0 mov FPU_TYPE, 0 jne end_get_fpuid check_control_word: fnstcw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS and ax, 103fh cmp ax, 3fh mov FPU_TYPE, 0 jne end_get_fpuid mov FPU_TYPE, 1 check_infinity: cmp CPU_TYPE, 3 jne end_get_fpuid fld1 fldz fdiv fld st fchs fcompp fstswword ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS mov FPU_TYPE, 2 sahf jz end_get_fpuid mov FPU_TYPE, 3 end_get_fpuid: ret get_fpuid endp
Re: Installing kernel 2.4
[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 instructions, etc. All of this on x86 could be dynamically detected. 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 size. If the compiler always aligned all functions and data on 16 byte boundries (NetWare) for all i386 code, it would run a lot faster. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Jeff regards, Davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
David Lang wrote: 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. The macros would be a problem. Some of the options, like MTRR, should be auto-detected. Jeff 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 On Tue, 7 Nov 2000, Jeff V. 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 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 CPU type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. :-) ;* ; ; check current processor type and state ; ;* public DetectProcessorInformation DetectProcessorInformation proc near mov ax, cs mov ds, ax mov es, ax pushf call get_cpuid call get_fpuid call print popf ret DetectProcessorInformation endp get_cpuid proc near check_8086: pushf pop ax mov cx, ax and ax, 0fffh push ax popf pushf pop ax and ax, 0f000h cmp ax, 0f000h; flag bits 12-15 are always set on an 8086 mov CPU_TYPE, 0 ; 8086 detected jeend_get_cpuid check_80286: orcx, 0f000h push cx popf pushf pop ax and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in real mode mov CPU_TYPE, 2 ; 80286 processor jzend_get_cpuid check_80386: mov bx, sp and sp, not 3 OPND32 pushf OPND32 pop ax OPND32 mov cx, ax OPND32 35h, 4h OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; AC bit won't toggle, 80386 detected mov sp, bx mov CPU_TYPE, 3 ; 80386 detected jz end_get_cpuid and sp, not 3 OPND32 push cx OPND32 popf mov sp, bx ; restore stack check_80486: mov CPU_TYPE, 4 ; default to 80486 OPND32 mov ax, cx OPND32 35h, 20h ; xor ID bit OPND32 push ax OPND32 popf OPND32 pushf OPND32 pop ax OPND32 xor ax, cx ; cant toggle ID bit je end_get_cpuid check_vendor: mov ID_FLAG, 1 OPND32 xor ax, ax CPUID OPND32 mov word ptr VENDOR_ID, bx OPND32 mov word ptr VENDOR_ID[+4], dx OPND32 mov word ptr VENDOR_ID[+8], cx mov si, offset VENDOR_ID mov di, offset intel_id mov cx, length intel_id compare: repecmpsb or cx, cx jnz end_get_cpuid intel_processor: mov INTEL_PROC, 1 cpuid_data: OPND32 cmp ax, 1 jl end_get_cpuid OPND32 xor ax, ax OPND32 inc ax CPUID mov byte ptr ds:STEPPING, al and STEPPING, STEPPING_MASK and al, MODEL_MASK shr al, MODEL_SHIFT mov byte ptr ds:CPU_MODEL, al and ax, FAMILY_MASK shr ax, FAMILY_SHIFT mov byte ptr ds:CPU_TYPE, al mov dword ptr FEATURE_FLAGS, edx end_get_cpuid: ret get_cpuid endp get_fpuid proc near fninit mov word ptr ds:FP_STATUS, 5a5ah fnstsw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS cmp al, 0 mov FPU_TYPE, 0 jne end_get_fpuid check_control_word: fnstcw word ptr ds:FP_STATUS mov ax, word ptr ds:FP_STATUS and ax, 103fh cmp ax, 3fh mov FPU_TYPE, 0 jne end_get_fpuid mov FPU_TYPE, 1 check_infinity: cmp CPU_TYPE, 3 jne
Re: Installing kernel 2.4
"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 type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. 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 size. ftp.timpanogas.org/manos/manos0817.tar.gz Look in the PE loader -- Microsoft's PE loader can do this since everything is RVA based. If you want to take the loader and put it in Linux, be my guest. You can even combine mutiple i86 segments all compiled under different options (or architectures) and bundle them into a single executable file -- not somthing gcc can do today -- even with DLL. This code is almost identical to the PE loader used in NT -- with one exception, I omit the fs:_THREAD_DLS startup code... 8) Jeff If the compiler always aligned all functions and data on 16 byte boundries (NetWare) for all i386 code, it would run a lot faster. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Jeff regards, Davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 cpu with lower optimizations and then abort with an error message? "Error: Kernel needs a PIII" sounds much better than just stoping dead. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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. All of this on x86 could be dynamically detected. Jeff, I think you miss the point that 100% dynamic detection comes with a penalty over the current system. Using CONFIG_M586 enables us to compile with Pentium-specific instructions, and eliminate any code specific to 386's or 486's. This includes inlining Pentium-specific code into drivers and the core kernel where possible, for the maximum possible performance. Your scheme doesn't work because of all the inlined code, nor does it support maximum performance code on all processors without massive code bloat... You do bring up a good point though. Users compile their own kernels to get the advantages I describe above. Vendors, on the other hand, must compile one-size-fits-all generic kernels. Your expertise and assistance would definitely benefit this case. One change I would like to make in 2.5.x along these lines -- the Alpha AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all processors/machines -- or CONFIG_ALPHA_$MYMACHINE. It would be nice to follow that model for x86 too. Currently, when I select CONFIG_M586, I get code for 686, etc. There is no way to simply say "Pentium and nothing else". Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 uncompress and to detect the cpu with lower optimizations and then abort with an error message? "Error: Kernel needs a PIII" sounds much better than just stoping dead. I agree... maybe we can solve this simply by giving the CPU detection module the -march=i386 flag hardcoded, or editing the bootstrap, or something like that... Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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, note use of "...align...": /usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o extable.o extable.c 2.4.x, note "preferred-stack-boundary" and generated asm code... gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /spare/cvs/linux_2_4/include/linux/modversions.h -c -o emd.o emd.c Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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, special instructions, etc. All of this on x86 could be dynamically detected. Jeff, I think you miss the point that 100% dynamic detection comes with a penalty over the current system. Using CONFIG_M586 enables us to compile with Pentium-specific instructions, and eliminate any code specific to 386's or 486's. This includes inlining Pentium-specific code into drivers and the core kernel where possible, for the maximum possible performance. Your scheme doesn't work because of all the inlined code, nor does it support maximum performance code on all processors without massive code bloat... You do bring up a good point though. Users compile their own kernels to get the advantages I describe above. Vendors, on the other hand, must compile one-size-fits-all generic kernels. Your expertise and assistance would definitely benefit this case. 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 type 2. Use PE. Jeff One change I would like to make in 2.5.x along these lines -- the Alpha AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all processors/machines -- or CONFIG_ALPHA_$MYMACHINE. It would be nice to follow that model for x86 too. Currently, when I select CONFIG_M586, I get code for 686, etc. There is no way to simply say "Pentium and nothing else". Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
Jeff, the kernel image is already pretty large. if you try and take what are basicly independant kernel images and put them in one file you will very quickly endup with something that is to large to use. As an example a kenel for a boot floppy needs to be 1.4MB compressed, it's not uncommon for it to be 800K compressed as it is, how do you fit even two of these on a disk. 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. 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: Installing kernel 2.4 "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 type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. 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 size. ftp.timpanogas.org/manos/manos0817.tar.gz Look in the PE loader -- Microsoft's PE loader can do this since everything is RVA based. If you want to take the loader and put it in Linux, be my guest. You can even combine mutiple i86 segments all compiled under different options (or architectures) and bundle them into a single executable file -- not somthing gcc can do today -- even with DLL. This code is almost identical to the PE loader used in NT -- with one exception, I omit the fs:_THREAD_DLS startup code... 8) Jeff If the compiler always aligned all functions and data on 16 byte boundries (NetWare) for all i386 code, it would run a lot faster. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Jeff regards, Davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
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 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, note use of "...align...": /usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o extable.o extable.c 2.4.x, note "preferred-stack-boundary" and generated asm code... gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /spare/cvs/linux_2_4/include/linux/modversions.h -c -o emd.o emd.c Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
"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 type 2. Use PE. The kernel isn't going non-ELF. Too painful, for dubious advantages, namely: The current gcc toolchain already supports what you suggest. I understand that some people have even put some thought into a bootloader that dynamically links your kernel on bootup, so this idea isn't new. It's a good idea though. Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Installing kernel 2.4
David Lang wrote: Jeff, the kernel image is already pretty large. if you try and take what are basicly independant kernel images and put them in one file you will very quickly endup with something that is to large to use. As an example a kenel for a boot floppy needs to be 1.4MB compressed, it's not uncommon for it to be 800K compressed as it is, how do you fit even two of these on a disk. 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 proposal on the best way to do this. In NetWare, we had indirections in the code all over the place. NT just make huge and fat programs (NTKRNLOS.DLL is absolutely huge). 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] Subject: Re: Installing kernel 2.4 "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 type, feature flags, special instructions, etc. All of this on x86 could be dynamically detected. 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 size. ftp.timpanogas.org/manos/manos0817.tar.gz Look in the PE loader -- Microsoft's PE loader can do this since everything is RVA based. If you want to take the loader and put it in Linux, be my guest. You can even combine mutiple i86 segments all compiled under different options (or architectures) and bundle them into a single executable file -- not somthing gcc can do today -- even with DLL. This code is almost identical to the PE loader used in NT -- with one exception, I omit the fs:_THREAD_DLS startup code... 8) Jeff If the compiler always aligned all functions and data on 16 byte boundries (NetWare) for all i386 code, it would run a lot faster. Cache line alignment could be an option in the loader after all, it's hte loader that locates data in memory. If Linux were PE based, relocation logic would be a snap with this model (like NT). Jeff regards, Davej. -- | Dave Jones [EMAIL PROTECTED] http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
