My comment is that if this is a locking change than it should be part of
the locking changes..
so it's just each of us 'batting' to put the patch in the other
I have no problem with changing it but 
I think that if it's needed to do locking, then
it should be part of the locking patch.
Otherwise the code looks like it's introducing a p variable for no reason 
except for the suser().

Since the code around the suser will be changing, it won't really increase
the size of the locking patch because that line will probably 
be included in the patch anyhow.

either way, it's water under the bridge at the moment.
I hope to start in milestone 3 as soon as I can now that 2 is checked in.
that will be the addition of thread and kse rceation and tracking code,
to allow the creation of threads indepdnednt of the creation of the 
process structure.

ALso there will need to be work on defining how the varous utilities that
extract statistics from the kernel should behave when 
they encounter a process with multiple threads.
(e.g. how does ps report multiple 'wmesg' values?)

On Wed, 12 Sep 2001, John Baldwin wrote:

> On 12-Sep-01 Ruslan Ermilov wrote:
> > Hello Julian!
> > 
> > Could you please post the list of all changed and new kernel
> > API functions so that -doc guys can keep up with this?
> > 
> > Like suser_td(9), etc.
> suser_td() is going away.  p_ucred in the KSE kernel is still per-process, and
> we need to hold the proc lock while we call suser() as a result (and we have to
> hold it for the result of the test, so pushing the lock down into suser_td() is
> not feasible).  Thus, code that does this:
>         error = suser_td(td);
>         if (error)
>                 return (error);
> is going to become this:
>         struct proc *p = td->td_proc;
>         PROC_LOCK(p);
>         error = suser(p);
>         if (error) {
>                 PROC_UNLOCK(p);
>                 return;
>         }
>         .... /* do stuff */
>         PROC_UNLOCK(p);
> I originally asked that the suser_td() changes not be made so that the locking
> code doesn't have to go back all of them out again thus increasing the overall
> diff size.
> -- 
> John Baldwin <[EMAIL PROTECTED]> --
> PGP Key:
> "Power Users Use the Power to Serve!"  -
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to