On Wed, Jun 25, 2014 at 09:46:16AM +, Taylor R Campbell wrote:
> Also, I wonder whether any file systems will ever change the length of
> the key for a vnode. Probably not.
As I recall from when I was looking at this a couple weeks ago (feels
like a minor eternity ago, but it can't be much
On Wed, Jun 25, 2014 at 11:57:11AM +0200, Manuel Bouyer wrote:
> On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote:
> > >> Any comments?
> > >
> > > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ?
> >
> > My change intends to make it clear whether a callout will be use
On Jun 26, 11:30am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: Fix netbsd32's getfh()
|
| Christos Zoulas writes:
| > Well, let's not propagate the evil design! I is is one thing having:
| >
| > void *p = malloc(n);
| > free(p);
| >
| > where you know p is going to be NUL
Christos Zoulas writes:
> Well, let's not propagate the evil design! I is is one thing having:
>
> void *p = malloc(n);
> free(p);
>
> where you know p is going to be NULL when it fails and another having:
>
> foo *p;
> error = allocate_foo(&p);
> free_foo(p);
>
>
In article <53ab0471.4080...@m00nbsd.net>,
Maxime Villard wrote:
>>
>> That should probably be:
>>
>> return error;
>>
>> since vfs_composefh_alloc() failed, and we should not be calling
>> vfs_composefh_free().
>
>Yes, but no. Actually, vfs_composefh_free() handles NULL correctl
Le 25/06/2014 17:28, Christos Zoulas a écrit :
> In article <53aa91a3.1070...@m00nbsd.net>,
> Maxime Villard wrote:
>> Hi,
>> Here is a patch to sync netbsd32 with the native getfh() syscall. In addition
>> to making it consistent, it also:
>>
>> a) fixes the return value:
>> } else
In article <53aa91a3.1070...@m00nbsd.net>,
Maxime Villard wrote:
>Hi,
>Here is a patch to sync netbsd32 with the native getfh() syscall. In addition
>to making it consistent, it also:
>
>a) fixes the return value:
> } else if (error == E2BIG) {
> error = copyou
On Wed, Jun 25, 2014 at 6:57 PM, Manuel Bouyer wrote:
> On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote:
>> >> Any comments?
>> >
>> > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ?
>>
>> My change intends to make it clear whether a callout will be used
>> or not. I
Hi,
Here is a patch to sync netbsd32 with the native getfh() syscall. In addition
to making it consistent, it also:
a) fixes the return value:
} else if (error == E2BIG) {
error = copyout(&sz, SCARG_P32(uap, fh_size),
sizeof(size_t));
}
h
hey,
On Wed, Jun 25, 2014 at 02:01:02AM +, Christos Zoulas wrote:
>
> Looks good at first glance. I would change all exported names to start
> with bootcfg_ and BOOTCFG_; most of them do already.
i'm glad you suggested this this. all new names were prefixed with
bootcfg_ and BOOTCFG_ respec
Date: Wed, 25 Jun 2014 12:04:30 +0200
From: "J. Hannken-Illjes"
Using "memcpy(__UNCONST(node->vn_key.vk_key), new_key, new_key_len)"
works but I'm not sure if __UNCONST is the right way to go.
I think __UNCONST is the right way to go -- removing const from the
API itself is certainly
On 25 Jun 2014, at 11:46, Taylor R Campbell
wrote:
> Date: Wed, 25 Jun 2014 11:24:16 +0200
> From: "J. Hannken-Illjes"
>
> The attached diff adds a new vcache operation
>
> void
> vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len,
> void
On Wed, Jun 25, 2014 at 06:51:06PM +0900, Ryota Ozaki wrote:
> >> Any comments?
> >
> > why not change in6_if_link_up() to use a delay >= 1 instead of 0 ?
>
> My change intends to make it clear whether a callout will be used
> or not. I think it's error-prone.
for me, it's clear that a timeout of
On Wed, Jun 25, 2014 at 4:30 PM, Manuel Bouyer wrote:
> On Wed, Jun 25, 2014 at 02:43:16PM +0900, Ryota Ozaki wrote:
>> Hi,
>>
>> I found a strange behavior of if_wm that
>> its interrupt handler may call its if_start
>> (xmit function) eventually. I don't think
>> it's sane. It makes difficult to
Date: Wed, 25 Jun 2014 11:24:16 +0200
From: "J. Hannken-Illjes"
The attached diff adds a new vcache operation
void
vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len,
void *new_key, size_t new_key_len)
to atomically change the key o
The attached diff adds a new vcache operation
void
vcache_rekey(struct mount *mp, void *old_key, size_t old_key_len,
void *new_key, size_t new_key_len)
to atomically change the key of a cached vnode. As the key is no longer
constant remove "const" from all key argumen
On Wed, Jun 25, 2014 at 02:43:16PM +0900, Ryota Ozaki wrote:
> Hi,
>
> I found a strange behavior of if_wm that
> its interrupt handler may call its if_start
> (xmit function) eventually. I don't think
> it's sane. It makes difficult to use mutex for MP.
>
> Here is a call trace:
> wm_intr => wm_
17 matches
Mail list logo