Re: libnv

[Jason Thorpe <thorpej%me.com@localhost>]

> On Aug 27, 2018, at 2:25 PM, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 
> On Mon, Aug 27, 2018 at 08:41:43AM -0700, Jason Thorpe wrote:
>>> [proplib]
>> 
>> Let me try to address these points one by one:
> 
> Now that you're back, can you explain a few more basic points about
> proplib?

I'll do my best to remember :-)

> (a) What's its mission? Is it supposed to be a data *storage* library,
> that is, the data lives in proplib and you do proplib accesses to
> extract the bits of it you want as you need them? Or is it supposed to
> be a data *transfer* library, that is, the data lives somewhere else
> and the expectation is that when you receive a proplib bundle that you
> immediately unpack it into its own data structures? (Note that saving
> to disk and loading back later is roughly comparable to sending and
> receiving among entities -- that's not what this question is about.)

It can be either.

Consider the case of properties on device_t's ... it's the storage medium for that information.

Or consider the case of a configuration file ... this isn't really the same thing as "saving state out to disk and reading it back in later", it's one application serializing the information in a standard way to be consumed by another ... and how the consumer deals with it is really up to them.

Or consider the case of wanting to collect some information from the kernel for consumption by userland (for display purposes, or whatever) ... but you want to isolate the receiver from the implementation details of the kernel sender.

Some additional utility functions could make it easier to use in various situations, but it's intent is to be "useful wherever" 

> (b) What's its data model? Is it supposed to handle hierarchical
> tree-structured data of the kind you might find in an ordinary
> programming language's native data types? Or is it supposed to support
> graph-structured data where many locations can share references to
> common values or sub-objects?

The former is how it's generally used, but it shares references to common sub-objects as a memory saving measure (either by assuming you use the API that manipulates the objects directly and do this yourself, or by de-duping certain immutable objects, as with prop_number_t).  There is not attempt to detect cycles, however, so y'know, exercise caution.

> (c) And also, what's its data model? What was the criterion used to
> determine which atom types it supports?

The data types supported by Apple XML property lists, with the following caveats:

-- No attempt to support <real> or <date>.  There is no reason those could not be added, but their use in standalone and kernel environments is not feasible; they could certainly be excluded based on #ifdef...

-- I serialized unsigned numbers as hex (and assume that hex numbers that are read in are unsigned), and serialize signed as decimal.  I believe macOS will read both decimal and hex, but always writes out in decimal.  I think.  I should double-check.

I captured bool as a separate object type, as in CoreFoundation (CFBoolean), rather than in the number object as in Foundation (NSNumber).

-- thorpej