Re: fs-independent quotas

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Nov 15, 2011 at 07:56:09PM +0100, Manuel Bouyer wrote:

 > > Do we expect NetBSD developers to be checking in handlers for
 > > functionally equivalent binary formats that are *more* likely to
 > > cause a crash if invalid data are presented?  That does not seem
 > > good.
 > 
 > If you pass e.g. a string to the legacy quotactl syscall instead of
 > the required data structure, the kernel won't notice and will use
 > the bogus data.

That's no different from any other system call, though.

 > > Whether text or binary, the data have to be validated before being
 > > used.  Text or binary, code that doesn't do that is simply buggy.
 > 
 > But it's easier to validate a text format than a binary one.

But we don't have any schema handling or validation code for proplib
bundles. One can write checks by hand, but then they're likely to be
incomplete and/or wrong, and it ends up not being a net win. Also, the
more validation you do the less you can use the approach below.

 > > I think that if we aren't _actually_ going to provide backward
 > > compatibility in some way _now_, it doesn't matter.  Either way, to
 > > actually get sane semantics, versioning is required.
 > 
 > The actual quotactl interface has a version number embeeded, for
 > this reason.  But, for example, some fields can be added to the
 > strucure without changing the version number. The consumer will
 > just notice if the new field is present or not and real with it;
 > this provides backward and forward compat (older consumers will
 > just ignore the new fields).  This is somethig you can't do with a
 > binary format.

Well, yes it is (see uvmexp_sysctl for example) but besides that, as
I've pointed out before, this only works if you can predict in advance
what kinds of changes you expect. Otherwise, when you get a proplib
bundle that contains unexpected data, it fails the validation checks
and you die with an error.

Also, without schema handling for proplib do you really expect this
kind of ad hoc approach to be workable over a span of years, involving
multiple releases and possibly 3rd-party code?

(While I see the code you put in netatalk uses only struct
ufs_quota_entry and not the proplib bundles directly, you've been
arguing in this thread that struct ufs_quota_entry (after being
renamed) isn't good enough in the long term. Even though I don't
believe this, I do expect your arguments to be self-consistent...)

-- 
David A. Holland
dholland%netbsd.org@localhost