Re: 2.4.19pre3aa2

[Bill Davidsen]

On Thu, 14 Mar 2002, Dave Jones wrote:

> On Thu, Mar 14, 2002 at 03:28:01AM +0100, Andrea Arcangeli wrote:
>  > Only in 2.4.19pre3aa2: 21_pte-highmem-f00f-1
>  > 
>  > 	vmalloc called before smp_init was an hack, right way
>  > 	is to use fixmap. CONFIG_M686 doesn't mean much these
>  > 	days, but it's ok and probably most vendors will use it
>  > 	for the smp kernels, so it will save 4096 of the vmalloc space.
>  > 	I just didn't wanted to clobber the code with || CONFIG_K7 ||
>  > 	CONFIG_... | ... given all the other f00f stuff is also
>  > 	conditional only to M686 and probably nobody bothered to compile
>  > 	it out for my same reason 
> 
>  Brian Gerst had a patch a few months back to introduce a CONFIG_F00F
>  if a relevant CONFIG_Mxxx was chosen[1]. It never got applied anywhere, but makes
>  more sense than the CONFIG_M686 we currently use. 
>  
> [1] 386/486/586. With addition of my Vendor choice menu, we could even further
>     narrow it down to Intel only.

  Since vendors (and consultants) like to build a single kernel for use on
multiple machines, it would be nice if this could be done by some init
code (released) and a module. I don't know what the overhead would be,
perhaps the runtime code is so small it's not worth doing. Does that mean
it's not worth doing the option either? It certainly would seen desirable
to check for the F00F bug and if the code to handle it was not present
refuse to boot right away.

  The code actually looks so small as to be unworthy of an option, given
that many people would set it off not knowing was it was much less whether
they needed it. This is not like a missing FPU where you can do a graceful
reject of the instructions, if you have the bug and not the fix you are
vulnerable to sudden total failures, correct?

-- 
bill davidsen <[e-mail]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.