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. > > Releasing a V4 is provably correct but suboptimal for 32-bit UMLs, where V3 > and V4 would coincide. And actually, we've been lucky with this bug - it can > be completely avoided.
I'm having a related problem. This is with SuSE 10.0, kernel 2.6.13, with a SKAS3 patch in the host (I tried and failed to determine *which* patch), and UML utilities 20040114 (same behavior with utilities 20040406). Architecture is i386 (Pentium-M). I create a COW file and it comes out in the default v3 format. When UML starts, the kernel complains "Size mismatch (206158430208 vs 805306368) of COW header vs backing file". The numbers are 3x2^36 vs 3x2^28 (768 MB). I dumped the header and looked at the source: uml_mkcow puts the size in network byte order using htonll() (_bswap64). My guess is that the kernel does not invert the swap, where it does so for all the other fields, but I was not able to see in the kernel sources where this was (not) happening -- the provided sources use cow.c which is nearly identical to cow.c for the utilities, and I can see the call to ntohll and its definition as _bswap64. 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. 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, 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. Why (in format v3) is everything in network byte order? 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. You would rely on a mismatch of the magic number to recognize an endian mismatch. 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. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key) ------------------------------------------------------- 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
