> > hpa moved it (And some others) during his 2.3.99 big cleanup of setup.c
> > and friends.
> Hmm most of them were gone, but f00f is indeed still there in 2.4.15-pre6
The move went the other way. bugs.h -> setup.c
As well as f00f, things like the K6 bug check got moved there too.
tbh, I don't agree with hiding such code in a .h file. A better approach
may have been to split off a bugs.c file in arch/i386/kernel that gets
called after we've done CPU identification.
I'd like to shrink setup.c by moving a lot of things out of there.
If you look at what we currently have in that file..
- (unmaintained?) SGI visws support.
- bootmem allocator.
- CPU identification.
- CPU feature enabling/disabling.
- CPU errata workarounds.
Whilst you get to know your way around the 3000 or so lines after hacking
there a few times, it's constantly growing with each new CPU we support.
I think it's going to come to a point where this has to be split up to
some extent to keep it maintainable.
Something on my list for 2.5. I've already got patches doing some of this,
but theres still work to do.
> This particular bug hits all 586s so we're safe in this regard.
Good point. I had forgotten that. (And likewise, SMP K6's are unlikely)
In which case, I guess the reason was to get code 'hidden' in header
files in a common place.
> > It's questionable we should support such nightmare scenarios, but
> > as this is __initcode anyway, it's not that big a deal.
> ahh but isn't that the beauty of Linux ;)
Of course 8)
-- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/