[Horrible patch] Make TagLib build on (embedded) systems without a global filesystem namespace
ed at nuxi.nl
Wed Nov 18 15:22:16 UTC 2015
I happen to have a patch for TagLib that is in no shape of getting
upstreamed, but I thought I'd get in touch to hear your thoughts.
CloudABI is a UNIX-like runtime environment that I've been developing
that is built on the concept of pure capability-based security. It
allows you to more easily build testable and securely sandboxed
software. More details, including a recording of a talk at a
conference, can be found here: https://nuxi.nl/.
What's pretty awesome is that TagLib builds pretty well on CloudABI,
except for the part where I expected it would fail. CloudABI only
allows you to open files relative to directories that have already
been opened. In practice this means: open() does not exist, but
openat() does. By applying the following patch, TagLib is at least
capable of processing files through IOStreams:
I'd argue that such a patch is not specific to CloudABI, as it's also
useful if you want to use TagLib in an environment that doesn't run a
full operating system (e.g., the firmware of a music playing device).
It would be nice if TagLib would support such a use case out of the
box, but if this is infeasible, it would be nice if people could
enable this manually without too much patching.
What really blows up the size of this patch right now is that it needs
to remove a number of constructors from every individual file format
module. My question is, could we somehow eliminate all the explicit
constructors from those classes and keep all file I/O restricted to a
part of the code?
Ed Schouten <ed at nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
More information about the taglib-devel