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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
