search

accre / lstore-lio

Implementation of the L-Store filesystem
http://www.lstore.org
1 stars 1 forks source link

Make stable API/ABI #27

Open PerilousApricot opened 9 years ago

PerilousApricot commented 9 years ago

Instead of shipping the whole universe in the devel package, we should take this as an inspiration:

https://github.com/google/leveldb/blob/master/include/leveldb/c.h

"Client" applications only get pointers to opaque blobs, meaning that changing the internals of lstore doesn't require a recompile for all clients.

tacketar commented 9 years ago

That works in some cases but not others. For example it'll work if you have "my_type *a" but will fail to compile if "my_type a" is used.
Certain things I always use a pointer for; others I try to instantiate the actual variable statically, like making an array of them, etc.

Alan

On 11/9/2015 12:07 PM, Andrew Melo wrote:

Instead of shipping the whole universe in the devel package, we should take this as an inspiration:

https://github.com/google/leveldb/blob/master/include/leveldb/c.h

"Client" applications only get pointers to opaque blobs, meaning that changing the internals of lstore doesn't require a recompile for all clients.

— Reply to this email directly or view it on GitHub https://github.com/accre/lstore-lio/issues/27.

PerilousApricot commented 9 years ago

Right, but that's the whole point behind the stability -- if a client allocates an lstore struct on the stack, then we change the size of that struct, the all of the code breaks. By forcing the user to NOT mess with lstore structs, it leaves us free to modify them as we wish.

tacketar commented 9 years ago

I know but you also can cause memory fragmentation issues if you don't.
What I'm trying to get it is there are some things that give better performance if they are exposed (op_generic_t) and others it doesn't matter with and can be kept opaque.

Alan

PerilousApricot commented 9 years ago

Currently, we know that any changes to the lfs structs will force every single consumer of the interface to recompile. On the other hand, we suspect that probably there is performance issues.

There's nothing keeping us from doing it "clean" first, profiling where the performance hit is, then adding the right bits to support alloca() or something similar later.