On 19 Nov, 2014, at 00:34 , Masao Uebayashi wrote:
> On Wed, Nov 19, 2014 at 1:05 AM, Dennis Ferguson
> wrote:
>>
>> On 18 Nov, 2014, at 22:13 , Masao Uebayashi wrote:
>>> In the TAILQ case, where readers iterate a list by TAILQ_FOREACH(),
>>> TAILQ_REMOVE() is safely used as the update operat
On Wed, Nov 19, 2014 at 11:24 AM, Ryota Ozaki wrote:
> Weird :-/
I don't think so. For fast paths to access data really fast, slow
paths take a little way around (pre-allocation, etc). This is a fair
trade-off. If you can achieve such a goal (e.g. lockless access of
list) without restructuring
On Wed, Nov 19, 2014 at 3:11 AM, Taylor R Campbell
wrote:
>Date: Tue, 18 Nov 2014 13:31:49 +0900
>From: Ryota Ozaki
>
>I have to say sorry for my bad writing; I misled you about
>"free an ifnet object" due to my forgetfulness about the fact that
>an ifnet object is normally em
On Wed, Nov 19, 2014 at 12:18 AM, Masao Uebayashi wrote:
> On Mon, Nov 17, 2014 at 7:03 PM, Ryota Ozaki wrote:
>> - http://www.netbsd.org/~ozaki-r/psz-ifnet.diff
>
> IFNET_RENTER();
> IFNET_FOREACH() {
> if->if_watchdog();
> }
> IFNET_REXIT();
>
> This is not safe; if_watchdog() may resen
On Wed, Nov 19, 2014 at 10:15 AM, Masao Uebayashi wrote:
> On Wed, Nov 19, 2014 at 2:53 AM, Taylor R Campbell
> wrote:
>> The one tricky detail is that after a reader has fetched the tqe_next
>> pointer, it must issue a membar_consumer before dereferencing the
>> pointer: otherwise there is no gu
On Wed, Nov 19, 2014 at 2:53 AM, Taylor R Campbell
wrote:
> The one tricky detail is that after a reader has fetched the tqe_next
> pointer, it must issue a membar_consumer before dereferencing the
> pointer: otherwise there is no guarantee about the order in which the
> CPU will fetch the tqe_nex
On Tue, Nov 11, 2014 at 06:35:48PM -0500, Christos Zoulas wrote:
> On Nov 11, 11:11pm, mar...@duskware.de (Martin Husemann) wrote:
> -- Subject: Re: Converting kernel printf() to aprint_*() or log()
>
> | That sounds like a good plan, please correct me if I understood
> | wrong:
> |
> | - create
Hello,
This patch tries to support USB 3.0 for xhci.
xhci is still at best experimental.
Don't use it on production servers even though it looks work well.
Fixes:
- USB hubs should work.
- The root hub of xhci is now changed to have separated SS and HS ports,
so that SS and HS hubs in 3.0 h
Date: Tue, 18 Nov 2014 13:31:49 +0900
From: Ryota Ozaki
I have to say sorry for my bad writing; I misled you about
"free an ifnet object" due to my forgetfulness about the fact that
an ifnet object is normally embedded into a softc of each driver
(via ethercom) in NetBSD. (I.e.,
Date: Wed, 19 Nov 2014 00:05:05 +0800
From: Dennis Ferguson
Also, the TAILQ macros depend on a type pun fairly similar to the one
that did in the CIRCLEQ macros and hence have a lifetime which extends
only to some future version of the compiler smart enough to recognize
that and
Date: Tue, 18 Nov 2014 23:13:34 +0900
From: Masao Uebayashi
In pserialize_perform(), context switches are made on all CPUs. After
pserialize_perform(), all readers on all CPUs see the update data.
The data old data item is safely destroyed.
In the TAILQ case, where readers ite
On Wed, Nov 19, 2014 at 1:05 AM, Dennis Ferguson
wrote:
>
> On 18 Nov, 2014, at 22:13 , Masao Uebayashi wrote:
>> In the TAILQ case, where readers iterate a list by TAILQ_FOREACH(),
>> TAILQ_REMOVE() is safely used as the update operation, because:
>>
>> - Readers only see tqe_next in TAILQ_FOREA
On 18 Nov, 2014, at 22:13 , Masao Uebayashi wrote:
> In the TAILQ case, where readers iterate a list by TAILQ_FOREACH(),
> TAILQ_REMOVE() is safely used as the update operation, because:
>
> - Readers only see tqe_next in TAILQ_FOREACH(), and
> - Pointer assignment (done in TAILQ_REMOVE()) is at
On Mon, Nov 17, 2014 at 7:03 PM, Ryota Ozaki wrote:
> - http://www.netbsd.org/~ozaki-r/psz-ifnet.diff
IFNET_RENTER();
IFNET_FOREACH() {
if->if_watchdog();
}
IFNET_REXIT();
This is not safe; if_watchdog() may resend packets, too slow operation
to do in critical section.
I think you need
I thought I kind of understood how pserialize(9) works, but the manual
confused me:
mutex_enter(&writer_psz_lock);
/*
* Perform the updates (e.g. remove data items from a list).
*/
...
pserialize_perform(object->psz);
Hello,
On 11/18/14 19:21, Nick Hudson wrote:
On 10/31/14 03:59, Takahiro HAYASHI wrote:
hello,
This patch tries to support 3.0 hubs for xhci.
still xhci is at best experimental.
Thanks for working on this. Are you tracking other BSDs?
I retrieve FreeBSD, OpenBSD, and Linux src but not so
On 10/31/14 03:59, Takahiro HAYASHI wrote:
hello,
This patch tries to support 3.0 hubs for xhci.
still xhci is at best experimental.
Thanks for working on this. Are you tracking other BSDs?
Can you update the diff to -current?
Thanks,
Nick
17 matches
Mail list logo
