On Thu, 7/30/15, Hooman Fazaeli wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "freebsd-net@freebsd.org"
Date: Thursday, July 30, 2015, 2:35 PM
On 7/30/2015 5:22 AM,
Laurie Jennings v
On 7/30/2015 5:22 AM, Laurie Jennings via freebsd-net wrote:
On Wed, 7/29/15, John-Mark Gurney wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "John Baldwin" , freebsd-net@freebsd.org
Date: Wednesd
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Thu, 7/30/15, John Baldwin wrote:
Subject: Re: Locking Memory Question
To: "K. Macy"
Cc: "freebsd-net@freebsd.org" , "John-Mark Gurney"
, "Laurie Jennings"
Date: Thursday, July 30, 2015, 10:16 AM
On Wednesday, July 29, 2015 11:28:03 PM K. Macy wrote:
> >>
> >> Im not clear how I'd do that. the data being passed up from the kernel is
> >> a variable size. To use copyout I'd have to pass a
> >> pointer with a static buffer, right?
> >
> > Correct, you can pass along the size, and if it's not
>>
>> Im not clear how I'd do that. the data being passed up from the kernel is a
>> variable size. To use copyout I'd have to pass a
>> pointer with a static buffer, right?
>
> Correct, you can pass along the size, and if it's not large enough
> try again... Less than ideal...
>
>> Is there a way
Laurie Jennings wrote this message on Wed, Jul 29, 2015 at 17:52 -0700:
>
> On Wed, 7/29/15, John-Mark Gurney wrote:
>
> Subject: Re: Locking Memory Question
> To: "Laurie Jennings"
> Cc: "John Baldwin" , free
On Wednesday, July 29, 2015 03:26:46 PM Laurie Jennings wrote:
>
> I have a problem and I can't quite figure out where to look. This is what Im
> doing:
>
> I have an IOCTL to read a block of data, but the data is too large to return
> via ioctl. So to get the data,
> I allocate a block in a ke
On Wed, 7/29/15, John-Mark Gurney wrote:
Subject: Re: Locking Memory Question
To: "Laurie Jennings"
Cc: "John Baldwin" , freebsd-net@freebsd.org
Date: Wednesday, July 29, 2015, 7:25 PM
Laurie Jennings via
freebsd-net w
Laurie Jennings via freebsd-net wrote this message on Wed, Jul 29, 2015 at
15:26 -0700:
>
> I have a problem and I can't quite figure out where to look. This is what Im
> doing:
>
> I have an IOCTL to read a block of data, but the data is too large to return
> via ioctl. So to get the data,
>
On Sat, 16 Oct 2004 [EMAIL PROTECTED] wrote:
> @@ -71,12 +71,14 @@
> scope6_ifattach(ifp)
> struct ifnet *ifp;
> {
> - int s = splnet();
> +
> struct scope6_id *sid;
>
> sid = (struct scope6_id *)malloc(sizeof(*sid), M_IFADDR, M_WAITOK);
> bzero(sid, sizeof(*sid));
On 2004-10-16 18:22, [EMAIL PROTECTED] wrote:
> Howdy,
>
> Here is a proposed set of diffs for locking fixes in the
> scope6.c module. Please let me know anyone has questions or
> comments.
>
> Thanks,
> George
I'm not a networking expert, but there are some style bugs you might
Robert Watson wrote:
There are some sections of the network stack, such as the KAME IPSEC
implementation, parts of IPv6, and some device drivers, which are not yet
completely MPSAFE. This may or may not be an issue depending on what
your requirements are. If you have any bug fixes or improvements
On Fri, 24 Sep 2004, Waldemar Kornewald wrote:
> > Once GIANT is really gone, it may be nearly that easy. We're a ways
> > from that though.
>
> So, the code is not fully thread-safe yet (we want to drop GIANT)? Then,
> I misunderstood something. Will 5.3 be freed of GIANT?
Including some com
On Thu, 23 Sep 2004, Waldemar Kornewald wrote:
> we at the Haiku networking team are considering a port of your 5.3
> netstack because it is thread-safe and making the old one (4.x, I think)
> thread-safe is probably a much bigger task.
>
> Now, I saw that the routing code seems to use macros f
On Fri, Sep 24, 2004 at 08:03:03AM +0200, Waldemar Kornewald wrote:
> Brooks Davis wrote:
> >>>You can implement mutexes using semaphores, but semaphores tend to be a
> >>>more expensive since they are more expressive them mutexes.
> >>
> >>Using a benaphore instead would improve speed significantl
Brooks Davis wrote:
Oh, now that we talk about alternatives: did you consider using iovecs
instead of mbufs? Be Inc. said that BONE, the new netstack of BeOS (now
Zeta), can handle huge amounts of data much better than mbufs because
iovecs reduce the number of copies made when fragmenting...thou
On Thu, Sep 23, 2004 at 12:22:33PM +0200, Waldemar Kornewald wrote:
> Hi again,
> we at the Haiku networking team are considering a port of your 5.3
> netstack because it is thread-safe and making the old one (4.x, I think)
> thread-safe is probably a much bigger task.
It depends on the model yo
On Sat, 21 Jun 2003, Hiten Pandya wrote:
> On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
> > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
> > about mallocing data w/ a lock aquired.
> >
> > dmesg output:
> > malloc() of "64" with the following non-
Hiten Pandya wrote:
> On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
> > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
> > about mallocing data w/ a lock aquired.
> >
> > dmesg output:
> > malloc() of "64" with the following non-sleepablelocks held:
> >
On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
> I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
> about mallocing data w/ a lock aquired.
>
> dmesg output:
> malloc() of "64" with the following non-sleepablelocks held:
> exclusive sleep mutex netisr loc
Could you run with debug.witness_ddb and get a stack trace for the
warning?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 19 Jun 2003, John-Mark Gurney wrote:
> I am running FreeBSD 5.1-R on a sparc64 machine,
23 matches
Mail list logo
