Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a replacement for sqfs_writer_t in libsquashfs #91

Open
AgentD opened this issue Aug 3, 2021 · 1 comment
Open

Add a replacement for sqfs_writer_t in libsquashfs #91

AgentD opened this issue Aug 3, 2021 · 1 comment

Comments

@AgentD
Copy link
Owner

AgentD commented Aug 3, 2021

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.
@AgentD
Copy link
Owner Author

AgentD commented Aug 3, 2021

An appropriate API for the writer would probably be shaped something like this:

  • Create from a description struct
  • writer_mkdir/writer_mknod/writer_symlink/...
  • writer_begin_file, writer_append_file_data, writer_end_file
  • writer_begin_xattr, writer_append_xattr, writer_end_xattr
  • flush to disk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant