From: Blaisorblade <bla...@ya...> - 2005-12-20 17:25:37
|
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 |