[LinuxBIOS] [PATCH][LAR] New LAR access functions

Stefan Reinauer stepan at coresystems.de
Thu Jul 12 19:12:28 CEST 2007


* Peter Stuge <peter at stuge.se> [070712 18:37]:
> > int is 32bit on all GNU architectures I know that could
> > theoretically run LinuxBIOS.
> 
> My point is that this is lar and not LB. While LB is completely tied
> to the architecture we want lar to be the opposite. I expect lar and
> larballs to be platform independent, just like other archivers and
> good file systems. :)
 
Sure. But this is the code that fixes up the x86 bootblock in a lar
file. How many other uses on non x86 systems do you expect to see over
time for this very purpose?
You are right though, this stuff should work on non-x86 platforms, in
case someone is cross compiling for x86.

> lar shouldn't be an x86 only thing, should it?
 
Since LinuxBIOSv3 is x86 only at the moment, I am not sure we should try
to imply something that is not there. The rest of the code is rather
portable, but creating x86 reset vectors is something very specific to
the x86 platform, no matter how much we abstract it. 
When we add support for a second platform, this code should of course be
executed conditionally, in case the image is going to be an x86 bios
image. on some platform the bootblock will not be part of the lar as the reset
vector is 0 and so there is no room for a lar header before that.

lar images will be linuxbios images in 99.99% of the time. I agree we
want this to be flexible, but nobody is ever gonna use it to archive her
mp3s (well who knows... ;)
 
> > What kind of situation that realisticly happens would produce such
> > an issue? i.e. While a payload builds a lar, or while LinuxBIOS is
> > compiled?
> 
> Interactive buildrom and automated v3 abuild running at the same
> time e.g. (In the same place.)
> 
> Yes, it's rather theoretical and there's no point in jumping through
> hoops trying to recover from it - I'm requesting a way to measure
> that the larball was broken by someone else and that lar doesn't
> create a crazy big file.

Oh not at all, this is a very good example. You are right. We should
think of this.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




More information about the coreboot mailing list