> > No. We _don't_ know the type of the data. A filesystem entrusts us with a
> > token to keep in the PAG on its behalf. However, since this is meant to be
> > a generic mechanism, it's entirely dependent on the fs as to what's in the
> > blob.
>
> But you do know the type of the data in the blob... it's char* fsname,
> const void* key and const void* data, according to your code.
We only partially know the data type (btw you should ignore the const's).
> struct fsblob {
> const char* fsname;
> const void* key;
> size_t keysize;
> const void* data;
> size_t datasize;
> };
There shouldn't be any consts in there, or else the pointers have to be cast
prior to freeing.
So I'd have to do three kmalloc's instead of just the one (assuming struct
fsblob was folded back into struct vfs_token)...
> Your method loses on additional complexity, and wins on speed.
Yours may use more memory overhead, though that's not easy to judge. Also yours
is more complex in that there's more bits of memory to keep track of. OTOH,
your suggestion may permit sharing of fsname and maybe also key under some
circumstances.
> However, unless it's really, really speed sensitive code, I would go for
> KISS any day.
OTOH, resources are very precious, and the complexity is actually
straightforward and can be wrapped with macros or inline funcs.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:51 EST