I don't know exactly what you are trying to do, but won't this
make the generic-kernel case harder?
In an ideal world, a generic kernel would be able to determine which type of
processor it is running on, and run optimally on that.
Won't this patch require you to recompile your kernel for each alpha
implmentation? (EV4 vs. EV5 vs. EV6)
Why not have them defined in all cases, and then properly select the
right value at run time? Or is this not possible?
Compaq: High Performance Server Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com |C|O|M|P|A|Q| email@example.com
------------------- See the results at www.spec.org -----------------------
On Mon, 20 Mar 2000 firstname.lastname@example.org wrote:
> Linus Torvalds wrote:
> > It's much better to have specific CONFIG_xxx options that are set
> > automatically depending on the CPU type (see, for example, the way the x86
> > stuff sets "CONFIG_X86_WP_WORKS_OK" or whatever we called those options).
> > That makes for much more readable code, and makes the configure scripts
> > work correctly on dependencies.
> > So I'd suggest a CONFIG_L1_CACHELINE define for the size of the L1
> > cacheline instead of having CPU defines and then checking those.
> > Linus
> CONFIG_X86_WP_WORKS_OK only takes boolean values so I tried a compromise.
> I now use the config.h way, don't add any new CONFIG_xx options but still
> test cpu type in cache.h.
> It should work with i386 as well but I don't know how the cache lines vary
> across the many versions.
-- To unsubscribe: send e-mail to email@example.com with 'unsubscribe' as the subject. Do not send it to firstname.lastname@example.org
This archive was generated by hypermail version 2a22 on Sat Apr 1 04:15:01 2000 PST
Send any problems or questions about this archive to email@example.com.