Re: apex-1.4.5
On Sat, Aug 19, 2006 at 07:23:14AM +0930, Rod Whitby wrote:
> 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 :-)
NP. Just an FYI.
> 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.
And, if we return to this, I think we should add a skip (@0+16) to the
ramdisk partition so that APEX still has a plain view of the data.
Which forces us to ask the question: what does the data length mean
when there are skips?
Perhaps we should make two ramdisk partitions. One with no skip and a
data_length equal to the ramdisk as well as the 16 byte SERCOMM
header; one with a skip @0+16 and a data_length describing only the
ramdisk data. The first would be called ramdisk1, and the second
would be called ramdisk. This way, we can reasonably make the
data_length reflect the true count of valid bytes in the 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.
I like order as well and cruft deserves elimination. If we implement
the data_length, there is no reason to keep the SERCOMM header. That
said, it doesn't really matter to me one way or another except that
I'd really like to present a clean view of the ramdisk to APEX just as
we've done for the kernel.
> > 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.
That isn't true anymore. The kernel no longer has a SERCOMM header.
At least, not a valid one.
> Martin, sorry for the extra work caused by my lack of foresight.
:-)
All I want is for us to come to an end with changing this stuff.
Pusing out a new release of APEX for each little change is a bit of a
hassle. Unless there are objections, I would urge that we either put
a skip at the start of the ramdisk partition, or we make two
partitions where one has the skip and one doesn't.
Cheers.
Reply to: