Re: [akaros] Go 1.4

Nice! Well done! In addition to the ‚.‘, dont forget about the fake UTF ‚/‚ symbol for symbols that match to packages like „runtime/cgo“ as symbols in the C Code. Barret Rhoden schrieb am Do. 6. Sep. 2018 um 18:15: > Hi - > > Thanks to Brian's efforts this summer, we have a working Go 1.4 port

Re: [akaros] Code Review - Packed Core allocation strategy

sched: Touch up the packed scheduler > parlib: Make bitmask.h more compilable > parlib: Move perf's xlib to parlib > perf: Rename the ros_ core_set code > parlib: Move core_sets to parlib > parlib: Move the provisioning of cores to a PID > sched

Re: [akaros] Happy World Giraffe Day!

Hooray! I know where my Christmas bonus is going this year! - US$2,500 could pay for one GPS satellite collar to monitor giraffe movements remotely (incl. download time) Do I get to pick the giraffe and can I track it myself? Kevin Barret Rhoden schrieb am Mi.

Re: [akaros] It's always a bug in... spin the wheel!

Unacceptable. On Thu, May 25, 2017 at 12:49 PM Barret Rhoden wrote: > Hi - > > We're all familiar with the "It's always a bug in X" line. The usual > suspects include QEMU, KVM, Intel, the compiler, the NIC, the network, > etc. But of course never Akaros. (For those

Re: [akaros] crazy ctors!

at 9:45 AM barret rhoden <b...@cs.berkeley.edu> wrote: > On 2017-02-08 at 16:26 Kevin Klues wrote: > > Why are there multiple copies of the parlib being loaded? Is it because > it > > is statically linked into both the binary and some other .so? I just > reread > > y

Re: [akaros] crazy ctors!

. On Wed, Feb 8, 2017 at 8:04 AM barret rhoden <b...@cs.berkeley.edu> wrote: > On 2017-01-29 at 4:07 Kevin Klues wrote: > > Nice. Or not so nice. Good to know. > > even more fun! > > it turns out my fix wasn't right. the attempt was to see if we ran the > init functio

Re: [akaros] crazy ctors!

Nice. Or not so nice. Good to know. barret rhoden schrieb am Sa. 28. Jan. 2017 um 19:11: > hi - > > it turns out that parlib's ctors, uthread_lib_init() and > vcore_lib_init(), can be run multiple times, despite the > init_once_racy() thing. > > any shared objects (.so but

Re: [akaros] Errors while trying to build the kernel. (#27)

Keep in mind that kern/src/error.c is generated at compile time. Take a look at the top of kern/src/Kbuild. If the cross compiler isn't working properly it wont be able to generate this file. On Tue, Feb 2, 2016 at 11:26 AM, Barret Rhoden wrote: > Hi - > > On 2016-02-02 at

Re: [akaros] CODE REVIEW: get rid of NULL error messages and provide some hint as to where the error occurred.

Not sure what the __STRINGIFY() macro is supposed to do, but I wold use #__LINE__ to convert it to a string. On Fri, Jan 22, 2016 at 10:56 AM, ron minnich wrote: > The following changes since commit 6ae8195b99f28d2f2735dcde2a723a4bde3142ef: > > Add taps for pipes.

Re: [akaros] [PATCH] Clean up 'devgen()' a bit.

That's fucked On Saturday, January 9, 2016, Dan Cross wrote: > On Sat, Jan 9, 2016 at 5:31 PM, barret rhoden > wrote: > >> On 2016-01-09 at 22:22 ron minnich wrote: >> > It was for . >> >> It was for

Re: [akaros] sleep tests

Feel free to shorten them. I mostly pictured them running in a Jenkins-like environment where the time they took to run was not as important. Alternatively, you could put them in their own category in kbuild and disable them via kconfig in your local setup On Tuesday, December 15, 2015, 'Davide

Re: [akaros] Rule for XCC

These are dependencies alfonso and I came up with a coupe of years ago. Probably not complete, but a good starting point: https://github.com/brho/akaros/blob/master/tools/jenkins/config/compilation_components.json On Mon, Dec 14, 2015 at 1:43 PM, 'Davide Libenzi' via Akaros

[akaros] Code Review - updates to ak-code-review

-code-review for you to fetch changes up to d25f262fe01b385bb56e4d856f05064038976c6c: Print ${remote}:${head} in link for code review (2015-11-25 07:17:06 -0800) Kevin Klues (2): Fix up some whitespace in ak-code-review.sh

Re: [akaros] [PATCH] Add the #vars device to export kernel variables

On Wed, Nov 25, 2015 at 10:25 AM, Kevin Klues <klue...@gmail.com> wrote: >> Hence this proposal: >> static Dirtab mystuff[] __vartab = { >> {"boot", {(uint64_t), 0, 0}, 0, 0555, "%x",}, >> }; > > I don't see how this let's you split the dec

Re: [akaros] [PATCH] Add the #vars device to export kernel variables

> Hence this proposal: > static Dirtab mystuff[] __vartab = { > {"boot", {(uint64_t), 0, 0}, 0, 0555, "%x",}, > }; I don't see how this let's you split the declaration of variables across files (as Davide's Macros does). It looks to me like you would have to edit the table in a single file for

Re: [akaros] [PATCH] Add the #vars device to export kernel variables

gt; > {"boot", {(uint64_t), 0, 0}, 0, 0555, "%x",}, > > Also, I am not sure what the __vartab is going to do. If put them all in one > section, you still need the section marker parsing. > > > On Wed, Nov 25, 2015 at 11:11 AM, ron minnich <rminn...@gmail.com

Re: [akaros] UT_ASSERT_M extra args

Whatever you want it to. For example: void *var = malloc(100); memset(var, 0, 100) UT_ASSERT_M("Malloc work!\n", testallzero(var), { free(var); }); // do something else with var now... On Wed, Nov 25, 2015 at 1:38 PM, Barret Rhoden wrote: > Hi - > > In this: > >

Re: [akaros] [PATCH] Add the #vars device to export kernel variables

lags; > }; > > Then the init code of the var file would just read those entries and > populate the var namespace. > > > > > On Tue, Nov 24, 2015 at 2:10 PM, Kevin Klues <klue...@gmail.com> wrote: >> >> I'm curious if we don't want to expose the topology in the

[akaros] Code Review - Packed Core allocation strategy

in the git repository at: g...@github.com:klueska/akaros corealloc-packed for you to fetch changes up to 0780d0382aad2350ef3106761d41383b0a11908b: Add implementation of packed core alloc strategy (2015-11-25 06:27:07 -0800) Kevin Klues

Re: [akaros] Code Review - Add support for libc's nanosleep, usleep, and sleep calls

On Tue, Nov 24, 2015 at 12:04 PM, Barret Rhoden <b...@cs.berkeley.edu> wrote: > Hi - > > On 2015-11-19 at 18:18 Kevin Klues <klue...@gmail.com> wrote: >> The changes in this request can be viewed online at: >> >> https://github.com/brho/akaros/compar

Re: [akaros] Code Review - Migrate copy to/from user to exception table based ones

Barret typically doesn't check his email on weekends, so I wouldn't expect a response to this until Monday... On Sat, Nov 14, 2015 at 5:29 AM, 'Davide Libenzi' via Akaros wrote: > Any news on this one? > > > On Fri, Nov 13, 2015 at 3:10 PM, Davide Libenzi

Re: [akaros] Re: Code Review - Sigpipe support

Looking more closely, this spelling error is in a commit message, not the code base. My workflow won't check for spelling errors in the commit message because it applies checkpatch as a pre-commit hook. On Fri, Nov 13, 2015 at 1:05 PM, Kevin Klues <klue...@gmail.com> wrote: > Hmm,

Re: [akaros] Re: Code Review - Sigpipe support

OK, fixed. And rebased onto master. On Fri, Nov 13, 2015 at 3:30 PM, Kevin Klues <klue...@gmail.com> wrote: > On Fri, Nov 13, 2015 at 3:25 PM, Kevin Klues <klue...@gmail.com> wrote: >> Comments below based on your comments. I also patched up a bug >> related to s

Re: [akaros] Code Review - Migrate include markers to use pragma once

To be clear to others following this, the rules from here forward are to use #pragma once in new header files, instead of the usual: #ifndef THING #define THING #endif On Wed, Nov 11, 2015 at 11:38 AM, Barret Rhoden wrote: > Thanks, merged to staging at

Re: [akaros] Code Review - New Akaros profiler

Yeah, I think that's what he's implying. On Wed, Nov 11, 2015 at 10:21 AM, 'Davide Libenzi' via Akaros wrote: > Should I rebase that branch against staging? > > > On Wed, Nov 11, 2015 at 10:06 AM, Davide Libenzi > wrote: >> >> On Wed, Nov 11, 2015

Re: [akaros] Unknown mbox type 0

Well, this particular bug comes from the fact that we never set up an mbox for vcore0 if max_vcores() == 0 (which it is if you only give the machine 1 core). https://github.com/brho/akaros/blob/master/user/parlib/vcore.c#L175 I have feeling that there are more consequences than this though. On

Re: [akaros] Unknown mbox type 0

; > > On Wed, Nov 11, 2015 at 6:43 PM, Kevin Klues <klue...@gmail.com> wrote: >> >> Well, this particular bug comes from the fact that we never set up an >> mbox for vcore0 if max_vcores() == 0 (which it is if you only give the >> machine 1 core). >> >