Re: Opencomm: proplib-based syscall

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Mon Apr 27 2009 at 03:09:34 -0400, der Mouse wrote:
> > In fact, fundamentally it is completely the same thing as the current
> > model [for mount(2)].  You can just as well pass uint8_t[] read from
> > a file and have the same problems and same responsibilities.
> 
> > Say the argument is
> [compressed vertically -dM]
> > struct { a; b; }
> 
> > And the relevant xml is <a></a><b></b>.  What needs to happen if you
> > need to add "c", change "a" or remove "b"?
> 
> Things that do _not_ happen: adding a "c" starts using uninitialized
> memory after the struct; changing "b" to "c" starts using old-userland
> "b" values as if they were "c" values.
> 
> Yes, some cases will return errors.  But they'll return sensible
> errors, not random errors that make no sense unless you look at how
> bits are getting reinterpreted (or, worse, non-errors because the
> reinterpreted bits made enough sense to be used).

This is no different than the current common scheme of including a
version number in the mount argument structure.  Except that it's *worse*
since you need to do checking in every slot instead of just once during
argument processing.  Now you will probably suggest adding a version
number to the prop dictionary?

> Not that I like proplib (and XML more generally); I don't.  But this
> actually is one case where it gets things righter than the old way.

I, on the other hand, do like XML and proplib, but haphazardly adding
undefined kernel interfaces and making handwavy claims that all is now
jolly is not the way to use them.