On Mar 15, 10:57am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: compat work.
[leaving an ifdef to identify compat only code that can be removed]
| That might be useful.
I agree.
| My goal was to ensure that compat code can be reached, whether it was
| built-in to the kernel with
On Wed, 14 Mar 2018, Christos Zoulas wrote:
On Mar 15, 10:11am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: compat work.
| (Adding tech-kern@ to cc)
|
| Such "factoring out" is far beyond my capabilities, especially when we
| get into areas such as the networking code. There are
On Mar 15, 10:11am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: compat work.
| (Adding tech-kern@ to cc)
|
| Such "factoring out" is far beyond my capabilities, especially when we
| get into areas such as the networking code. There are just too many
| parts of the system which I
(Adding tech-kern@ to cc)
Such "factoring out" is far beyond my capabilities, especially when we
get into areas such as the networking code. There are just too many
parts of the system which I do not adequately understand.
I can either maintain the current capabilities, warts and all, or I
On 13.03.2018 13:26, Robert Elz wrote:
> Sure - I was not suggesting that anything shouild be done to this code to
> make it run faster - I had seen that "could just use ..." comment ages ago,
> and (as I assume its original author did, even more ages previously) that
> it just wasn't worth the
On Wed, Mar 14, 2018 at 01:06:53PM +, co...@sdf.org wrote:
> Hi I am looking at code related to PR 53096 (really important please
> look at it too), I came across this code, in vfs_vnode.c vrelel:
>
>
> 732 mutex_exit(vp->v_interlock);
> 733 error =
Hi I am looking at code related to PR 53096 (really important please
look at it too), I came across this code, in vfs_vnode.c vrelel:
732 mutex_exit(vp->v_interlock);
733 error = vn_lock(vp,
734 LK_EXCLUSIVE | LK_RETRY | (force ? 0
