| eeh@netbsd.org writes:
| > | what does it mean?  since they don't have an obvious fixed size,
| > | they're not strictly speaking an array...  (or do you mean, string
| > | pointer and array of string pointers... i don't think so?)
| > 
| > No, an array of strings is a buffer full of NUL terminated strings
| > up to the length of the buffer.  So you go traverse the buffer, 
| > looking for NULs, and set your pointers 1 byte beyond that until
| > you run out of buffer.
|
| OK.  (BTW, Assuming you think this type of representation of a list of
| NUL-terminated strings is The Right Thing, why did you add an extra
| NUL to the end of the list of <whichever> names returned by sysctl?
| why not just terminate in the same way, i.e., by running out of
| buffer?)

That code only applies to the "name" field of the property.  The data
field should not be touched.  The reason for that code is primarily to
prevent kernel panics from badly formed structures passed in from userland.

| > | > | I'm thinking that maybe 'setprop' should reject an attempt to change
| > | > | an existing property's type.  not sure tho.
| > | > 
| > | > Once again, I don't see why the database code should be setting policy.
| > |
| > | That seems reasonable.  On the other hand, can you think of real cases
| > | where you _would_ want the type to change at run time?
| > 
| > Switching from a single integer to an array of integers, or the other
| > way around, is certainly understandable.
|
| in general, from a single foo to an array of foo.  but i'm still not
| sure...  the thought goes something like:
|
| if you tolerate an array of foo, you can say "array of foo" up front,
| even if there's only one element in that array.
|
| If that's not desirable, the code could explicitly allow that case
| (conversion from a single element to an array w/ elements the same
| size as the original) w/o much trouble, i think...

Kernel code usually shouldn't care about the type.  That's only to 
help userland programs print out the data.

Anyway, the type of a property can be easily changed by removing
it and then inserting a new property with the same name and a different
type.  

I suppose you could argue that the semantics of preventing that sort
of operation is the same as requiring explicit type-casts, but typecasts
do not incur extra overhead.

| > | Is it necessarily true that different databases _must_ have different
| > | 'types' of contents?  e.g. one could imagine (and this is totally
| > | constructed 8-) something like:
| > |
| > | 	default audio device db:
| > |
| > | 		objects: channels: input, output, mixer, ... ?
| > |
| > | 		properties associated with those objects:
| > | 			(who knows, something about audio).
| > |
| > | 	audio device a db:
| > |
| > | 		same type of thing
| > |
| > | 	audio device b db:
| > |
| > | 		same thing...
| > |
| > | then at init of a device you might want to copy all of its params from
| > | the default params...
| > |
| > | i suppose you could use a single db to do this, but then you need to
| > | construct object ids out of ptrs + channel numbers, etc.  kinda gross.
| > 
| > In this case I'd say you really wanted to implement this with one database,
| > and the object identifiers would be pointers to individual channels....
| > 
| > The problem with allowing copying from one database to another is that
| > the object identifier space is potentially completely different.  Writing
| > code to do that is quite trivial, but I'm not sure I want to consider what
| > the implication of allowing that sort of operation would be on the database
| > abstraction.
|
| Err, I was specifically thinking of something along the lines of:
|
| 	copy all properties of object ob1 in db1
| 	so that they're attached to object ob1 in db2.
|
| (i.e., the user would need to specify the object in the second, and
| therefore issues of the 'object identifier space' and/or meanings of
| the object ids would be theirs to sort out.  I _wasn't_ thinking "copy
| this object into this other database, with the same object
| identifier.)
|
| Anyway, if there's a need for it in the future, it shouldn't be hard
| to add, so *punt*.
|
|
| > Maybe we should change all references of `quad' to `int64_t' in all the
| > manpages.
|
| probably.  8-)
|
|
| > | perhaps the right answer here is (assuming the desire is to keep
| > | sysctl's 'mib' a set of integers) to redefine them to be uint32_t's or
| > | int32_t's...
| > |
| > | I think that'd solve both problems, w/ no compatibility issues for
| > | current platforms.
| > 
| > That's a good idea, but outside the scope of this.
|
| it's not _quite_ outside the scope of this.  you're shoehorning a
| (possibly-)wider fixed-size type down on to the existing array of
| 'int's.
|
| since you aren't actually guaranteed that an 'int' will have a fixed
| size, and it's important to know how they map... you're forced to
| either assume something about 'int', or fix the use of 'int's.
|
| Historically, assumptions about non-fixed-size type sizes have been
| bad ones.  8-)

IMHO the sysctl kernel interface is broken and needs to be replaced.
But that is outside the scope of this project.  I suppose that's something
to do for NetBSD 2.0 8^)

| > I prefer to have explicit conversions.  They cause less problems in the 
| > long run than passing blocks of memory.
|
| I think I agree.
|
|
| > I'll change the wording to define 
| > it as explicitly big-endian.  I suppose providing a set of macros for this 
| > operation would be a good idea.
|
| Yes, good.
|
|
|
| thanks!
|
| chris