[Toybox] non-GPLv3 mtools?

[enh]

On Mon, Mar 14, 2016 at 10:05 PM, Rob Landley <rob at landley.net> wrote:
> On 03/14/2016 10:36 PM, enh wrote:
>> a non-GPLv3 mtools would be nice for UEFI purposes.
>
> That's on my todo list, and actually not that hard. I could bump it up,
> it was just post 1.0 because it's not in any of the priority roadmap
> categories. (Build tools, posix, lsb, existing android.)

UEFI seems to be a direction things are moving in. there's one
instance in the tree already (the HiKey dev board), but it seems like
it's not just for x86 any more...

>> (actually, better than mtools would be "take this directory and give
>> me a corresponding FAT[1] image".)
>
> Yes. A genfatfs ala genext2fs. (Well, vfat with windows 95 long filenames.)
>
>> i don't know how many requests you need before you put things on the
>> roadmap, but afaik there's no non-GPLv3 alternative here, which seems
>> like a good niche for someone to fill...
>
> Putting stuff on the roadmap is easy. Moving stuff to the top of the
> todo list is harder. :)
>
> That said, part of the reason I did dirtree was so I could scan all the
> directory metadata ahead of time, so I could make it work like an archiver.
>
> Basically every mkXXXfs command toybox has should also have a genXXXfs
> version, and I want it so you can stream the output.

yeah, that sounds great.

> I can "tar cz dirname | ssh blah tar xvz" which doesn't work if you have
> to mmap the file to write to it.) I ran into the fact that the ext2
> superblock has total used/free block counts, and then the inode and
> block allocation tables come before the file data, so in order to write
> it out in sequence I had to read ahead at least all the file metadata
> for the entire filesystem before writing the first block. And I didn't
> have a thing that could do that, so I mothballed it until I wrote one...
>
> I should get back to that. :)
>
>> ___
>> 1. okay, not really FAT ("The file system supported by the Extensible
>> Firmware Interface is based on the FAT file system. EFI defines a
>> specific version of FAT that is explicitly documented and testable.
>> Conformance to the EFI specification and its associate reference
>> documents is the only definition of FAT that needs to be implemented
>> to support EFI. To differentiate the EFI file system from pure FAT, a
>> new partition file system type has been defined.") but FAT-ish.
>
> I dunno about fat-ish but I've done some research on the topic. I was
> more or less looking at Linux's vfat. (I can probably ignore fat12 but
> fat16 still exists, and fat32 is probably the standard now?)
>
> I also poked a bit at qemu's "create a fat volume from this directory"
> mode a few years ago.
>
> Do you have a reference to the EFI fat spec?

the quotation was from here:

http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1458074042.0