[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: