Hi,
On 2016/04/27 0:27, Taylor R Campbell wrote:
>Date: Tue, 26 Apr 2016 13:22:40 +0900
>From: Kengo NAKAHARA
>
>Does anyone have any comments or objections? If there is no objection,
>I will commit this patch after a few days or a few weeks.
>http://www.netbsd.org/~knaka
On Wed, Apr 27, 2016 at 04:27:56PM +0900, Kengo NAKAHARA wrote:
> I have considered it a little, so that I use if_transmit member directly
> because of the clean of caller and ifq_enqueue() implementation. I feel
> like avoiding extra if-else statement in fast path every time. However,
> as you poi
Date: Wed, 27 Apr 2016 16:27:56 +0900
From: Kengo NAKAHARA
On 2016/04/27 0:27, Taylor R Campbell wrote:
> - Why not call the struct ifnet member `if_enqueue'?
>
> It may be confusing to add a new verb `transmit' to a lexicon that
> already has a lot of local jargon.
Fair
On Sun, Apr 24, 2016 at 07:11:37PM +, David Holland wrote:
> Since you said fuse has a way to do that but it doesn't work for our
> fuse, I guess the right way forward is to make it work in our fuse.
> What's required? Just send an arbitrary ID associated with the open
> through puffs to userla
On Wed, Apr 27, 2016 at 03:58:43PM +, Emmanuel Dreyfus wrote:
> On Sun, Apr 24, 2016 at 07:11:37PM +, David Holland wrote:
> > Since you said fuse has a way to do that but it doesn't work for our
> > fuse, I guess the right way forward is to make it work in our fuse.
> > What's required
David Holland wrote:
> ok, I don't understand: even assuming that stashing this information
> in the credentials is the right place (which I don't think I agree
> with but haven't really formed a coherent opinion about yet)... why on
> earth should it be conditional?
Because if the filesystem do
On Wed, Apr 27, 2016 at 03:58:43PM +, Emmanuel Dreyfus wrote:
> On Sun, Apr 24, 2016 at 07:11:37PM +, David Holland wrote:
> > Since you said fuse has a way to do that but it doesn't work for our
> > fuse, I guess the right way forward is to make it work in our fuse.
> > What's required? Ju
Joerg Sonnenberger wrote:
> Can you please start with a consistent proposal of what the end result
> should look like before adding random pieces? I'm sure, but this feels
> like a very adhoc hack to cover a few corner cases for some strange out
> of tree target without a clean idea on how it aff
Hi joerg@n.o,
On 2016/04/27 17:53, Joerg Sonnenberger wrote:
> On Wed, Apr 27, 2016 at 04:27:56PM +0900, Kengo NAKAHARA wrote:
>> I have considered it a little, so that I use if_transmit member directly
>> because of the clean of caller and ifq_enqueue() implementation. I feel
>> like avoiding ext
Hi, riastradh@n.o,
On 2016/04/27 23:49, Taylor R Campbell wrote:
>Date: Wed, 27 Apr 2016 16:27:56 +0900
>From: Kengo NAKAHARA
>
>On 2016/04/27 0:27, Taylor R Campbell wrote:
>> - Why not call the struct ifnet member `if_enqueue'?
>>
>> It may be confusing to add a new ve
> > Can you please start with a consistent proposal of what the end result
> > should look like before adding random pieces? I'm sure, but this feels
> > like a very adhoc hack to cover a few corner cases for some strange out
> > of tree target without a clean idea on how it affects the long term
>
matthew green wrote:
> you do realise that kauth_cred_t is shared across processes in
> some cases but not all, right?
VFS uses a kauth_cred_t from struct file f_cred field, which is tied to
the struct file. The value is initialized as curlwp->l_cred in
fd_allocfile().
My proposed patch repla
Emmanuel Dreyfus writes:
> matthew green wrote:
>
> > you do realise that kauth_cred_t is shared across processes in
> > some cases but not all, right?
>
> VFS uses a kauth_cred_t from struct file f_cred field, which is tied to
> the struct file. The value is initialized as curlwp->l_cred in
>
13 matches
Mail list logo
