[Changed subject so we can keep these two threads separate.] Stephen Warren wrote: >> I've been thinking about the API, and I'm starting to think more and >> more that all our uint8_t* and uint32_t* stuff really should just be a >> void* blob which is internally a structure with the uint8_t* and the >> size inside of it. Not only do I think of that array as a opaque blob >> to the user, but I don't want our API/ABI to have to change when we >> make it into an mmap pointer or some other thing. > > Well, on all platforms, mmap (or the equivalent) will always map the file > to some memory location, so we can always have a pointer and size. What is > different, is that we may need extra information to manage the mapping.
True, but it may be a void* pointer, or a uint8_t* pointer, or some other
kind of pointer. I want to hide that from the user and pass back a void* ptr
that points to:
struct lc_blob {
uint8_t* data;
uint32_t size;
}
That way, if we move to mmap(), that can become:
struct lc_blob {
void* data;
uint32_t size;
int fd;
}
and the user doesn't need to know. Or another possibility we move to some
XML library which means for config files we have to grab the binary blob
first, which means we'll have:
struct lc_blob {
xml_struct data;
<something> bin_data;
int bin_size;
}
Ack!
> Actually, I'd also like to consider the case of an app that internally
> creates an "EZHex" file in memory and passes this into libconcord. I guess
> to support this, all we would need to add is an API like
> create_Data_struct_from_memory_region, that remembers it doesn't need to
> free the memory buffer, just the Data structure. Similarly, apps might
> want to construct raw binary config-updates or firmware blobs, and pass
> these into the write_*_to_remote functions. So, we shouldn't preclude
> that. Perhaps the file IO functions should handle Data to allow for
> mmaping in the future, but the remote interaction functions should either
> still take in/size, *or* be documented to only use the public portions of
> struct Data, so and app can create its own.
Hmmm. You bring up an interesting point. Honestly, I don't see it happening
anytime soon, but we probably shouldn't preclude it.
I have to think about this. Your suggestion doesn't actually solve the
problem I have, which is that I don't want to pass around a uint8_t* which I
REALLY don't that format lasting very long in the codebase, and us moving to
an XML library or something instead.
Hmm.
What about passing around a void* like I suggested with the size and all
hidden inside of but an export_blob() API that dumps it to something easy -
such as our uint8_t* with a size, and of course an import_blob() to go with?
Initially this will be kinda of silly because the internal representation
will be identical, but it gives us the freedom to change at will and the
flexibility to let users hack on stuff.
FURTHER, it means they'll never screw with OUR copy of the data - they have
to *ask* us to take it via import_blob(), so we can do some sanity checking
and such if we'd like.
Hmm, I kinda like that.
Thoughts?
--
Phil Dibowitz [EMAIL PROTECTED]
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ concordance-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/concordance-devel
