You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The libcommon.a helper library currently contains an sqfs_writer_t implementation that uses libsquashfs and libfstree together to provide a simple, high level interface for creating squashfs images.
It would benefit users of libsquashfs to build a somewhat more generic replacement into libsquashfs.
There are still a few points that need to be ironed out for the interface design:
Given that the interface would be much more high-level/opaque, how to properly generate error messages.
At some point, it might be extended to not just generating squashfs images, but to read an existing image and allow editing it.
Would it be reasonable to also add a dead-simple filesystem like API to read from squashfs images? Should that include caching? Asynchronous read & decompress?
Should the two somehow be able to reasonably interoperate? If so, how?
Of course, some of the later points are not yet relevant as long as simple editing, or a high-level reader is not planned, but should be kept in mind to make API extensible enough.
This move has so far not been done for two reasons:
Open questions regarding the design of a proper API/ABI for it.
The lack of a need, as it was assumed that most projects doing filesystem manipulation would have their own high-level layer that libsquashfs would be integrated into.
The text was updated successfully, but these errors were encountered:
The libcommon.a helper library currently contains an sqfs_writer_t implementation that uses libsquashfs and libfstree together to provide a simple, high level interface for creating squashfs images.
It would benefit users of libsquashfs to build a somewhat more generic replacement into libsquashfs.
There are still a few points that need to be ironed out for the interface design:
Of course, some of the later points are not yet relevant as long as simple editing, or a high-level reader is not planned, but should be kept in mind to make API extensible enough.
This move has so far not been done for two reasons:
The text was updated successfully, but these errors were encountered: