Define Key Value CCB.

[imp]

Summary

Add wrapper function xpt_kv_get which gets a value based on its key
(or rather sends a XPT_KV_GET CCB to the SIM associated with the path).

Add wrapper function xpt_kv_set which sets the value (or rather sends
a XPT_KV_SET CCB to the SIM associated with the path).

Define XPT_KV_GET which allows periphs to lookup key values associated
with the path by the SIM, if it exists.

Define XPT_KV_SET which allows setting values for a key associated
with the path by the SIM, if it exists and is allowed.

Sponsored by: Netflix

Test Plan

Here's the basis for a KV CCB that lets periphs get generic values from the SIM about that path. The keys are strings and the values are arbitrary data.

This is a preliminary design review.

[imp]

update with wrapper function.

[imp]

Just to document a conversation Scott and I had:
(1) What about multiple keys?
(2) What about multiple returns?
(3) Should we just assume this is 1 page?
(4) How do we do chaining when we send CCBs from userland: not allow it at all or force userland to use less efficient methods
(5) How do SIMs deal with packing and unpacking?

Scott drew this on the white board:

ccb_hdr
int num_keys;
key_offset_1 (maybe also key_len_1)

key_offset_2 <etc>

key1
key2
key3
etc

And the return data would come back in a similar fashion. For the return side, we'd have to preserve length for the values because they aren't all strings.

He and I quibbled a bit over encoding, etc, which I've not recorded here since they don't matter yet...

We need to worry about how much space we can use on the return path as well as keeping the key list around while we're packing the answers for return...

[chuck]

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

[imp]

In D14551#305404, @chuck wrote:

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

DEV_ADVINFO is more for servicing GEOM attribute requests about the device. There seems to be a fair amount of glue at the xpt layer to know about what GEOM wants to be returned.

My stuff is more for the PERIPH asking the SIM for info, as well as set stuff. However, you ask a fair question.

[chuck]

In D14551#305406, @imp wrote:

In D14551#305404, @chuck wrote:

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

DEV_ADVINFO is more for servicing GEOM attribute requests about the device. There seems to be a fair amount of glue at the xpt layer to know about what GEOM wants to be returned.

My stuff is more for the PERIPH asking the SIM for info, as well as set stuff. However, you ask a fair question.

So is the intent to support Object storage (as opposed to Block) via this new CCB type?

[imp]

In D14551#305421, @chuck wrote:

In D14551#305406, @imp wrote:

In D14551#305404, @chuck wrote:

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

DEV_ADVINFO is more for servicing GEOM attribute requests about the device. There seems to be a fair amount of glue at the xpt layer to know about what GEOM wants to be returned.

My stuff is more for the PERIPH asking the SIM for info, as well as set stuff. However, you ask a fair question.

So is the intent to support Object storage (as opposed to Block) via this new CCB type?

No, it's to make a more generalized version of DEV_ADVINFO. I'll be adding multiple keys to this as well. It isn't for supporting object store stuff.