Re: fs-independent quotas

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

On Thu, Nov 17, 2011 at 05:10:24PM +0100, Manuel Bouyer wrote:
 > > What am I missing?
 > 
 > the quotactl call has different commands, which takes different arguments.
 > For example, quotaon takes a string, while setquota takes a struct
 > describing the quotas to be set.
 > With the old quotactl, the kernel has no way to tell if it really got a
 > string of a struct dqblk (or something else); it can just interpret the
 > pointer as a string and see if it works. If instead of a string it got
 > a dqblk whose first 2 entries happends to be 0x6f6f622f 0x78300074,
 > you'll have troubles (you're doing quotaon on /boot).
 >
 > With a proplib format, the kernel knows it didn't get the right
 > argument (it didn't find a key "quotafile" with a string value in the
 > dictionary). Of course you can still do quotaon /boot if you really
 > wants to, but then it has been done on purpose, not just because
 > you gave the wrong pointer to quotactl().

This is about type-safety. It has nothing to do with compatibility,
forwards or backwards.

Unless we split quotactl(2) into multiple system calls, one per
operation, it can't be fully typesafe; C has no strictly type-safe way
to be polymorphic.

It can be made better than quotactl(path, int, int, void *), but only
a little. The important thing, I think, is that in my proposed world
quotactl() is no longer meant to be user-callable. (Maybe it should be
_quotactl() or __quotactl() so nobody calls it by accident.) Only
libquota calls it, and if you're that concerned about mismatched types
we can audit the libquota code.

And, btw, using proplib does not make the code type-safe. To the
contrary, in fact, even excluding the dynamic typing behavior, because
proplib's API is so borked. Look in its header files to see how many
of its typedefs are really void pointers, and be scared...

(Yes, this could be fixed by replacing proplib with something better
designed that does the same thing. That is not going to be happening
anytime particularly soon though.)

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