On 24-Feb-02 Julian Elischer wrote:
> I'm just saying that if this is the "simple p->p_ucred => td->td_ucred
>
> change that do only that and do the rewrite in a separate commit..
> I'm not against doing hte commit as is however.. it's only 3 small
> nits..
> the one that may be real is the ot
On 23-Feb-02 Julian Elischer wrote:
>
>
> On Fri, 22 Feb 2002, John Baldwin wrote:
>> http://www.FreeBSD.org/~jhb/patches/ucred.patch
>>
>
> The following diff removes the capacity to cope with the case when td is
> NULL. I presume it is there because it CAN be NULL. (Though I have not
> chec
I'm just saying that if this is the "simple p->p_ucred => td->td_ucred
change that do only that and do the rewrite in a separate commit..
I'm not against doing hte commit as is however.. it's only 3 small
nits..
the one that may be real is the other one I mention (I think in another
email) wher
Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800,
Julian Elischer said words to the effect of;
>
>
> On Fri, 22 Feb 2002, John Baldwin wrote:
>
> >
> > http://www.FreeBSD.org/~jhb/patches/ucred.patch
>
>
> the structural rewriting in kern_proc.c should be done as a separate
> co
On Fri, 22 Feb 2002, John Baldwin wrote:
>
> http://www.FreeBSD.org/~jhb/patches/ucred.patch
the structural rewriting in kern_proc.c should be done as a separate
commit. (though I agree it should be done)
the structural rewriting in kern/sysv_*.c
could be done as a separate commit as well.
On Fri, 22 Feb 2002, John Baldwin wrote:
> http://www.FreeBSD.org/~jhb/patches/ucred.patch
>
The following diff removes the capacity to cope with the case when td is
NULL. I presume it is there because it CAN be NULL. (Though I have not
checked further.)
--- //depot/vendor/freebsd/sys/fs/smbf
On 23-Feb-02 Jake Burkholder wrote:
> Apparently, On Fri, Feb 22, 2002 at 11:38:07PM -0500,
> John Baldwin said words to the effect of;
>
>> I'm currently testing the following patch whcih is a subset of the td_ucred
>> changes. It involves no API changes, but only contains 2 basic change
Apparently, On Fri, Feb 22, 2002 at 11:38:07PM -0500,
John Baldwin said words to the effect of;
> I'm currently testing the following patch whcih is a subset of the td_ucred
> changes. It involves no API changes, but only contains 2 basic changes:
>
> 1) We still need Giant when doing t
I can't look at it till tomorrow.
But I've been watching.
I'd be surprised if anything broke with what I've seen.
I'll look at it then if you haven;t commited by then.
On Sat, 23 Feb 2002, John Baldwin wrote:
>
> On 23-Feb-02 John Baldwin wrote:
> > I'm currently testing the following patch w
please feel free to commit.
If you break something so be it.
I've been watching your P4 commits, and have not seen any obvious problems
I assume that your "easy" changes are those you;ve been doing on P4.
On Fri, 22 Feb 2002, John Baldwin wrote:
> I'm currently testing the following patch whci
:> as found in getgroups(). Some of these changes, for example return()ing
:> in the middle of a procedure, are highly dependant on the removal of
:> Giant. goto's are questionable but replacing them with return()s in
:> the middle of a procedure isn't too hot an idea either.
:
:
On 23-Feb-02 Matthew Dillon wrote:
>:> I'm currently testing the following patch whcih is a subset of the td_ucred
>:> changes. It involves no API changes, but only contains 2 basic changes:
>:>
>:> 1) We still need Giant when doing the crhold() to set td_ucred in
>:>cred_update_thread().
:> I'm currently testing the following patch whcih is a subset of the td_ucred
:> changes. It involves no API changes, but only contains 2 basic changes:
:>
:> 1) We still need Giant when doing the crhold() to set td_ucred in
:>cred_update_thread(). This is an old bug that is my fault. I k
On 23-Feb-02 John Baldwin wrote:
> I'm currently testing the following patch whcih is a subset of the td_ucred
> changes. It involves no API changes, but only contains 2 basic changes:
>
> 1) We still need Giant when doing the crhold() to set td_ucred in
>cred_update_thread(). This is an o
14 matches
Mail list logo