Hello Darren,

Darren Reed wrote:

> You have a kauth_cred_getrefcnt().  Why?

It's just a replacement for pc->p_refcnt. The idea was to first get a
working tree and then work on cleaning up and removing things that are
not needed. If you'd take a look at some of the commits to the branch
you'd notice that this was done, mostly.

> Why do you want to return the refcnt?  Why do you care if the value
> is 4 or 5? 

I couldn't care less about it, but some code uses it.

> You have both kauth_cred_hold() and kauth_cred_dup().  Why ?

Same reason...

> i.e. rather than doing:
> 
> kauth_t *k;
> 
> k = something->kauth;
> kauth_cred_hold(k)

...and simply raising the reference count,

> do
> 
> kauth_t *k = kauth_cred_dup(something->kauth)

and allocate a new kauth_cred_t object from the memory pool.

> If kauth_cred_destroy() is never called directly, remove it from
> the man page and update the description of _free()

But it *IS* called directly, see nfs/nfs_socket.c; maybe that'll
change, for now it stays...

> In the description of kauth_cred_copy, when you say clone, do you
> mean you call kauth_cred_clone() ?  Otherwise, what is the purpose
> of this function?  The description seems, to me, confused, with
> the "reference count of 1" special case.

Yes. All the issues you are pointing out are *really* issues with the
way Unix had done credentials. The kauth(9) interface routines you point
out are simple drop-in replacements.

> I think you need to rework the entire document (and design?) where
> it concerns the management of the kauth_t objects themselves.

The document reflects what the -current interface is. It's a bad habit
of mine to keep documentation up to date with the code.

> It most definately is not ready for putting into -current but
> you should create a branch and put it on the branch so others
> can see the work in progress.

Dude, it is on a branch of its own for quite a while, other developers
have commented on the code in it too.

-e.

-- 
Elad Efrat