> I did not see either Bjo/rn Eriksson or Steve Schmidtke's comments on
> the user-mode-linux-devel list
Steve's patch was sent privately. Bjo/rn Eriksson's patch was sent to
the devel list on 12/12.
> There now are two #includes of <sys/types.h>
> and several #include
> order changes, were there some include header order dependances?
No order dependencies. As a personal preference, I like ordering headers
so that the <*.h> ones come first, followed by <sys/*.h>, <asm/*.h>, and the
odd ones after those. It also makes it easier to spot duplicates :-)
> The creat() call did seem to have rather too liberal permissions.
Yeah, I didn't see the point of making it executable...
> I also like the use of in_fd and now ubd.c should follow. Adage: In
> software if the same thing is done two places one of them will
> eventually be wrong.
Good point. It's tough to actually share code between a kernel pool and
a userspace utility, but maybe we can pull the COW code out of ubd_user.c
into a separate file which is copied into CVS /tools/uml_moo.
> But why seek backwards after reading part of the header into one var
> and then read all of it again into another?
I didn't want to split the header structs into a common part and a different
part and read the different part alone separately. It's simpler to read
the common portion of the header to figure out the version, and lseek back
to the start so the code can do the usual thing of reading the whole header
into the appropriate header struct.
> uml_moo should also be using lseek64 like ubd_user.c now does.
> To me it appeared that the V1->V2 header changes were to eliminate the
> word length and endianness dependancies of the V1 header. This
> produces the really odd "OOOM" yes upper case and reversed magic
> number in the V2 format.
The actual magic number doesn't matter just as long as it's somewhat
> But the word order and endianness dependancies were the reason to keep
> the V1 compatibility in the uml_moo program in the first place.
The V1 compatibility was to avoid screwing anyone during the transition
from V1 to V2.
> Which is still true by
> the way: ubd_test/set_bit still use native endian longs.
That was a mistake, and it's going to be fixed.
> I was trying to follow Linus's style guideline does uml/tools have a
> different preferred style?
Example of where I changed from Linus' style to something else?
> The magic number would look better if the string is treated as a
> string "MOOO" :) not a integer 0x4f4f4f4d :(. (strings are fairly
> endian free - integers are not)
It's a magic number and it's treated as such. It's not really a string, even
though it coincidentally seems to spell something :-)
> The COW format should have the data blocks page/sector aligned in the
> file so that a one block read of the ubd will correspond to only one
> block read on the COW file this offset should also be in the header.
They are aligned, at least on sector boundaries. Do you want better (i.e.
> The backing file name should have a length and the char array should
> be the last element in the COW header so MAXPATHLEN isn't always
You can't have a filename longer than MAXPATHLEN, so an arbitrary-length
counted string doesn't seem to make much sense apart from saving some space
in the header.
> And the vars after backing file are hard to find in a dump.
Moving the filename to the end seems reasonable.
> I would think that the backing file should always have a relative file
> refernece so that the common directory containing the COW and backing
> file could be moved.
This makes it impossible to run UML from a different location from the one
where you created the COW file, unless the backing path is taken to be
relative to the COW file. In that case, you can move both, but you can't
move only one. Long-term, I expect that there will be a system-wide repository
of backing files (i.e. in /usr/lib/uml or something) and users will have
their own collections of COW files backed by the system backing files.
They're going to want to be able to move them around, and they can't if the
paths are relative. You're assuming that there will be a common directory
for COW and backing files. I don't think that will be the case.
A more generic problem with relative paths is that they can contain useless
segments, and those segments might go away, making the COW file useless, even
though the backing file is available. One example is when the path goes a
symlink which later disappears. Another would be a path like
'../foo/../bar/backing_file'. If foo goes away, the COW file is useless.
You might argue that people who construct paths like that deserve to lose,
but that sort of thing is easy for a script to make.
As for moving backing files around, I'm planning on making 'ubd0=cow,back'
when the cow already knows what its backing file is to mean that back has
been moved and the header should be updated. The mtime and size checks
will still apply. If the move is across filesystems, then the mtime check
will fail, leaving us with the size, which is a bit thin. My thinking
right now is that we make the admin manually set the mtime back as a promise
that this really is the same backing file.
> Also how easy is it to insure that the exact path matches when moving
> files between processors with different endianness/word lengths?
That's a strcmp, which is word-length and byte-order independent. Am I