Messages in this thread | | | From | "ELEMENTI S.A." <> | Subject | RE: linux-2.3.31: drivers/char/drm/drmP.h does not allow 386 build | Date | Thu, 9 Dec 1999 17:07:05 -0300 |
| |
-----Mensaje original----- De: David Weinehall <tao@acc.umu.se> Para: Adam J. Richter <adam@yggdrasil.com> CC: faith@precisioninsight.com <faith@precisioninsight.com>; daryll@precisioninsight.com <daryll@precisioninsight.com>; linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>; rth@twiddle.net <rth@twiddle.net> Fecha: Jueves, 09 de Diciembre de 1999 01:18 p.m. Asunto: Re: linux-2.3.31: drivers/char/drm/drmP.h does not allow 386 build
>On Thu, 9 Dec 1999, Adam J. Richter wrote: > >> >Would it be sufficient if we >> >compiled using the CMPXCHG instruction and then did a run-time test for the >> >386 and never executed this instruction? >> >> Yes. That would be fine. I know that your code compiled just >> fine when I got rid of the ifdef that checked for 386, so I know >> the assembler will not choke on the instruction, even though the >> compiler is being called with -m386. >> >> Richard's solution sounds OK too. As you are probably aware, >> there have been similiar discussions about this type of approach >> to MMX and other x86 instruction additions. I guess it's a function >> of how much overhead you see as associated with the run time check >> for the 386 CPU. >> >> If the run time check for a 386 is a small overhead, but >> something you would still like to avoid when possible, and if >> do not want to implement Richard's proposed emulation for whatever >> reason, then you might want to consider arranging things so that >> you only compile in the checks if CONFIG_M386 is set, since not >> setting CONFIG_M386 will already generate a kernel that cannot run >> on a 386 (because it will compile in bswap instructions which do not exist >> on a 386). So, if CONFIG_M386 is not set, you know this kernel already >> can only run on a processor that supports cmpxchg, so you can skip the >> run time tests. The best style for doing this would be to define a >> symbol like CONFIG_X86_CMPXCHG in arch/i386/config.in, and test >> for that symbol. > >I get the feeling that we are adding more and more cruft to the M386 path, >that is only used for processors >386. While I can see the reasoning >behind this, maybe it's time to introduce a new compile-option. > >CONFIG_M386_GENERIC, which is the crufted version with compability for all >processors > >and > >CONFIG_M386, which is cruftfree and known to work on 386's, without any >optimisations for other processors. > >In my opinion, Linux is getting a bit too slow on 386's, without any real >reason. > > >/David Weinehall > _ _ > // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ >// Project MCA Linux hacker // Dance across the winter sky // >\> http://www.acc.umu.se/~tao/ </ Full colour fire </ > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.rutgers.edu >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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |