On Monday 19 December 2005 21:19, Jim Carter wrote: > On Fri, 16 Dec 2005, Blaisorblade wrote: > > On Thursday 15 December 2005 21:15, Jeff Dike wrote: > > > On Thu, Dec 15, 2005 at 05:26:44PM +0100, Blaisorblade wrote: > > > > The problem is that the same declaration is used in kernel sources. > > > > I.e., we have (likely) COW files generated from 64-bit machines using > > > > a different format from 32-bit ones. So we have two incompatible > > > > formats out there in the wild.
> > > Hummm, this seems to call for a V4. > > In short, not needed. > > Very short term solution is to build 32-bit and 64-bit uml_moo versions. > > With the existing code - i.e. compile -m32, compile normally. > When I sabotaged the byteswap in uml_mkcow and recompiled, my re-created > COW file was useable. An alternative would be to force v2 format, I think. I verified the code to write out a V2 header is missing, as expectable. > As compiled on i386 with gcc-4.0.2 dated 2005-09-01, uml_mkcow produced for > cow_header_v3.size an 8-byte field aligned on a 4-byte boundary. While > this doesn't seem to bother the Pentium-M which has no 64-bit data on the > bus, Pentium 1 (yes, the one produced in 1992 or so) uses an 8 byte bus, even if it's a 32-bit machine... > I would be inclined to re-order the data members so the size naturally > comes out on a 8-byte boundary, on the likely assumption that __u32 takes 4 > bytes. Even though time_t is 4 bytes, I would also stick mtime after the > size so that in however many years (when I'm pushing daisies) when time_t > is widened, that change will happen with no padding added. Both changes are a good idea - actually switching mtime to "unsigned long long" would do the job, but for now I'm trying to avoid creation of a V4. > Why (in format v3) is everything in network byte order? I'm not entitled to answer - I wasn't here when it was born, and the decision traces to V2. > Obviously so a COW > file can be created on a host of one endianness, and then used on a host > that goes the other way, e.g. create on Sparc or PPC, execute on i386. If > the kernel auto-creates the COW file, clearly this could never happen. > Perhaps there are scenarios I haven't thought of, > but dumps of COW headers > will be a lot easier to read if the native order is used. Exactly the opposite, unless you use an Arabian editor. Don't think so - big-endian is much more natural to read. Some books (say Intel manuals) make little-endian seem as much as natural, but they are cheating - they write numbers with byte 0 at the right, i.e. they write from right to left! And when reading a file, unless you have an editor writing right-to-left. > You would rely > on a mismatch of the magic number to recognize an endian mismatch. This is already done to distinguish V1 from V2, to read ->version field (yep, it too changed endianness). > I wish each patch had a title which could be printed when the UML boots -- > guest and host separately, since they might be different versions. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
