tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Opencomm: proplib-based syscall



Antti Kantee wrote:

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.

You keep taking one private case where the proposed syscall can be used
and treat it as the ultimate problem we're trying to solve.

That is not the case. All I asked is if there would be an objection for
such an interface, and input. What I really was interested in is what
uses other people can think of for it. I did not even post any code that
can be committed; in fact, the code I posted is *intentionally* isolated
for that very reason.

That said, I'd like to point out that you have received several examples
that you are ignoring for uses for such an interface: runtime generation
of syscalls/arguments, alternative to sysctl, alternative way to couple
access control to a certain functionality (if you have a pseudo device,
you're *limited* to the traditional Unix permission bits) -- less places
to "touch" when a change of security policy is desired, a data storage
format that can be readily externalized, sent on the wire, and inspected
by non-NetBSD machines, or machines that are not familiar with the ABI
of one NetBSD version or another, a data format where users should care
about whether one field or another is present or not -- and not whether
it changes the size/ordering of the structure, and so on.

Thanks,

-e.


Home | Main Index | Thread Index | Old Index