On 10/09/2013 03:25:27 AM, Conroy, Bradley Quentin wrote:
>Sort of moot at this point, I did a largeish rewrite. (Attached, I
>should be able to rsync it up to the site tonight.)
I'll wait on recoding it with the union of structs pointing to toybuf
then.
That would take care of the strict aliasing, reduced the memory foot-
print and simplified a bunch of code, but I'm interested to see how
you did it.
It was attached to the previous email.
>There are currently three obvious problems with it, all to do with
vfat:
>
>1) it always prints a LABEL even if it's all spaces or the magic "NO
>LABEL" value.
I think it is safe to check *offset==' ', but "NO LABEL"? really? Who
does that? I think I would consider that disk to be labeled.
According to http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html (and
some testing here) it's "NO NAME " (yes, space padded at the end)
and various format tools create that.
A vague todo item I've had is something mtools-like. The fat filesystem
is a bit unusual due to being 30 years old and very simple, things like
qemu generate it on the fly.
But for 1.0 I wanted to concentrate on the roadmap. That's why the
constant stream of commands not in the roadmap is so depressing; I
don't exactly want to say no to them, but dealing with them prevents me
from getting any closer to 1.0, and the project keeps getting bigger
and more complex without getting any closer to the original goals,
unless I mostly ignore outside contributions.
No clue how to deal with that. (I _have_ decided what I want to do
about the tcpsrv submission, which is add the relevant functionality to
netcat and make a "server" alias for that which is _not_ tcpsrv or
udpsrv because those are part of a larger suite of tools that do not
belong in toybox, and implementing part of that suite invites an
endless stream of questions about why I haven't got the rest of it.
So providing the functionality yes, opening that can of worms no.
But I also expect this to disappoint people, which is why I haven't
done it yet. (Saying no to code nobody ever asked me if I wanted makes
me the bad guy. Comes with the territory I guess...)
>2) The funky 32 bit uuid is printed big endian, when the other prints
>it little endian.
Yeah, fun stuff. There isn't a lot of conformity there either.
The thing is, FAT is one exception and NTFS is another (completely
different) exception. It's not "add a flag for endianness", so far this
is just a special case for a single filesystem.
Filesystem special cases I want to put in the C code after the table,
flags to indicate things that apply to more than one filesystem should
be in the table, so I need more dat about what the full table looks
like before finalizing the design. :)
>3) It prints the uuid hex all lower case, where vfat is uppercase and
>ext2 is lowercase. (Sigh.)
That is why I had %X in one and %x in the other. At least with a
union
of structs you can just use sizeof(fs->something.uuid) to get the size
and data,
No you can't, not unless you define your own type for each filesystem.
(Sizeof fat12/16 is 5. It would have to be a char array. I made it 64
bit integer.)
The special case code to deal with each member of the union means the C
code is large and complex even if the table isn't, plus this is an
array so it gets padded out to the largest possible size so you're not
actually saving any space...
but still have to track these nuances by masking some flags.
labelisUCS = 1
There is exactly one instance.
backwarduuid = 2
So far, exactly one instance.
capsuuid=4
Don't even know what that means.
halfbackwarduuid=8 (i think there is some other wierd nuance)
Again: dunno.
spaceisblanklabel=16
Can we just say a label of all whitespace is considered blank? Do we
really need a flag for that? (And again, what filesystems would this
apply to? If it's just one, then it's a special case not a flag...)
I note that the current FAT uuid is, at least, unique. If all you care
is recognizing devices you've seen before, we're done. Probably we care
about more than that, but I honestly dunno what the requirements are
here.
Rob
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
