Re: apex-1.4.5
Marc Singer wrote:
> Note that APEX doesn't care about the order of the skips. It sorts
> them by offset.
Understood - this is just so someone doing a hex dump of the image sees
a sensible order. It's easy to do, so let's do it. I like order :-)
>>> + 'header'=>($loader ? 0 : 16)},
>> I'd prefer to *always* put a header on the Ramdisk partition. The stock
>> Ramdisk partition has a header, so we should keep it for compatibility
>> (to ease upstream and downstream tools that need to deal with Ramdisks
>> presented to either RedBoot-based or APEX-bsaed systems.
>
> Um. Wasn't this what we were just talking about. Once the system
> uses APEX, there isn't a good reason to keep the header. The system
> cannot be booted without APEX, so ...
Right, but then we need the tool which extracts a ramdisk from a running
system, or from an image file, to know whether APEX is there or not.
Not a good situation. Please keep the header on the Ramdisk partition.
> I perfer to drop the SERCOMM header because it is an abomination.
> Everything needed can be present in the partition table.
The user never sees it, so the abomination is hidden.
> Also, we *just* asked Martin to remove the ramdisk partition header.
It appears I gave Martin a bum steer. For that I apologise. I asked
for the header associated with the stock ramdisk to remain in flash
where it always was. But I didn't consider the case where apex was
loaded, but we still want the ramdisk partition header even though it is
not used by Redboot, for upstream and downstream tool compatibility (and
for ease of documentation of NSLU2 image and partition formats).
The ability to say "NSLU2 kernel and Ramdisk partitions *always* have a
SerComm header, irrespective of which first or second stage bootloader
you are using" outweighs the hidden abomination, IMHO.
Martin, sorry for the extra work caused by my lack of foresight.
-- Rod
Reply to: