* Peter Stuge peter@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.