"Kevin O'Connor" kevin@koconnor.net writes:
On Tue, Aug 02, 2011 at 11:33:09AM +0200, Bjørn Mork wrote:
"Kevin O'Connor" kevin@koconnor.net writes:
Also, it's possible the code could try to use the f-segment if there are less than say 16 cpus and use high memory when more cpus are present.
How about a variant over the last suggestion: Don't actually care bout the number of CPUs, but just fall back to malloc_high if malloc_fseg fails?
This could make testing painful - small changes in the code could cause a different table layout that is OS visible. I'd prefer a more strict cutoff. Though, I suppose the cutoff could be by the table size itself instead of by number of CPUs.
This is of course your call to make...
But I must admit that I fail to see the advantage. I agree that having the table moved around depending on some variable is a problem. Which variable doesn't really matter. At least I don't see a fixed cutoff size as any more predictable than a f-segment allocation failure, given that I have no clue as to what SMBIOS table size is to be expected. Maybe go for the number of CPUs then. But what if additional data is added to the table, making f-segment allocation fail? Then you will end up with three different results depending on small changes instead of two:
1) nCPU <= 16 and f-segment allocation OK: SMBIOS in f-segment 2) nCPU > 16: SMBIOS in high mem 3) nCPU <= 16 and f-segment allocation failed: no SMBIOS table
I don't think that makes testing any less painful...
Anyway, I would appreciate if some solution was found which allowed JUNOS to boot with an unmodified SeaBIOS with SMBIOS enabled, as long as the number of CPUs is limited.
Bjørn