On 2015-10-30 at 20:13 "'Davide Libenzi' via Akaros"
wrote:
> I agree with you. It is wasted effort in the long term.
> Depends how many apps to be ported have a dependency of them.
Exactly - this was the tradeoff I was dealing with when I decided to
not do select/poll yet. Originally, I was mak
On 2015-10-30 at 17:02 "'Davide Libenzi' via Akaros"
wrote:
> To me, it can be a pretty big win to avoid CR3 reloads on high
> frequency event deliveries like network, for example.
Yeah, that's a good point. One of the things we do in a couple places
is keep a cr3 around for a while even if it's
from when that code was written:
commit 383648aa099a3974b397cf81d1a82969bf7814fc
Author: Barret Rhoden
Date: Tue Dec 9 22:44:37 2014 -0800
Per-cpu timer control for oprofile sampling
To use oprof now, you need to set the timer, then enable the profiling.
If/when we add other tr
On 2015-10-31 at 10:06 "'Davide Libenzi' via Akaros"
wrote:
> Moreover, I think the kprofinit is called at boot time, which
> allocates and sets up the profiler, even though nobody is using it.
> IMO the profiler should have zero cost if nobody is using it, and the
> setup should be done once the
ng loops in order to modify the output format; the
> > counter is that this is so small one could reintroduce them if
> > necessary.
> >
> > On Thu, Oct 15, 2015 at 1:53 PM, Barret Rhoden
> > wrote:
> >
> >> These problems and their fixes popped u
On 2015-11-05 at 14:20 "'Davide Libenzi' via Akaros"
wrote:
> Here is what I was thinking.
> There is an VM area of N pages, at KMSG within kernel only area, and
> at UMSG at user VM space.
> The user VM space [UMSG, UMSG+N] is out of mmap() reach.
> Userspace has an API we give them to create a m
On 2015-11-05 at 14:22 "'Davide Libenzi' via Akaros"
wrote:
> Example:
>
> / $ cat /prof/kptrace
> [ 8.102085467]:cpu0: kern/drivers/dev/kprof.c(227)
> Backtrace:
> #01 [<0xc207233e>] in trace_printk
Can we make trace_printk just do a print instead of a backtrace? T
Hi -
On 2015-10-29 at 14:32 Dan Cross wrote:
> [This is against a branch on /brho, but that's because it was
> in-flight before I created my own fork.]
>
> The following changes since commit
> 5025b06858b52dcd0a536e76f7da6e6e74c59589:
>
> Add the Inferno license to files we got from Inferno (
On 2015-11-09 at 14:17 "'Davide Libenzi' via Akaros"
wrote:
> I read that this weekend. Was on linked /.
> I agree with Linus, for one ☺
“There is no way in hell the problem there is the kernel,”
Torvalds said. “If you run a nuclear power plant that can kill
millions of pe
On 2015-10-31 at 09:18 "'Davide Libenzi' via Akaros"
wrote:
> I have also added the strcpy to/from user, but we seem to pass the
> length from userspace AFAICS.
> Up to you if you think they will become handy or not.
Overall, I like replacing memcpy_{to,from}_user, but I think the string
ops have
Thanks, merged to staging at 1165c2bda44b..df2c47c3a7f3 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/1165c2bda44b...df2c47c3a7f3
Barret
On 2015-10-31 at 16:33 "'Davide Libenzi' via Akaros"
wrote:
> While looking around at the timer code, I
On 2015-11-09 at 17:35 "'Davide Libenzi' via Akaros"
wrote:
> OK, I fixed the strcpy to/from user code, in the same branch.
Thanks, I'll take a look.
> For uaccess.h in RISCV, what do we want to do?
> I don't know it well enough, I don't have anything to build and test,
> and the only Linux thin
On 2015-11-09 at 15:41 "'Davide Libenzi' via Akaros"
wrote:
> > > + for (;; dst++, src++) {
> > > + int error = __get_user(dst, src, 1);
> > >
> > > - static_assert(ULIM % PGSIZE == 0 && ULIM != 0); // prevent
> > wrap-around
> > > + if (unlikely(error))
> > > +
On 2015-11-10 at 06:07 ron minnich wrote:
> I've been feeling for some time that we'd have to break out
> applications for akaros from the akaros tree itself. It's a necessary
> part of the maturation process; not every program should be in the
> kernel source tree :-)
Agreed, in general, though
Thanks, merged to staging at df2c47c3a7f3..9a8b7bed409e (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/df2c47c3a7f3...9a8b7bed409e
On 2015-11-02 at 11:11 Dan Cross wrote:
> The following changes since commit
> 2a9b3cdc47dbde55f9d125fde3e1183
Hi -
Looks good, just some minor stuff (below):
On 2015-11-02 at 19:19 "'Davide Libenzi' via Akaros"
wrote:
> This CL adds support for multiboot command line, and also adds an API
> to retrieve boot options.
> Tested with qemu -append option.
>
> https://github.com/brho/akaros/compare/master...
Thanks, merged to staging at 9a8b7bed409e..bd12c9c87fcc (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/9a8b7bed409e...bd12c9c87fcc
On 2015-11-03 at 08:33 Kevin Klues wrote:
> This CL adds a set of ak-scripts to the mainline akaros repostory.
Thanks, merged to staging at bd12c9c87fcc..4402cbebfec6 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/bd12c9c87fcc...4402cbebfec6
FYI - people need to rebuild glibc and then busybox. The easiest, but
slowest, way is to make xcc-upgrade-from-
On 2015-11-10 at 15:44 ron minnich wrote:
> I got worried that we were starting to bake in things that might make
> it hard to make this separation later. We'll see how it goes. We can
> always bring it back in. But I'd like to have a clear understanding
> of how we support code that we don't want
On 2015-11-10 at 08:11 "'Davide Libenzi' via Akaros"
wrote:
> On Tue, Nov 10, 2015 at 7:59 AM, Barret Rhoden
> wrote:
>
> > Two checkpatch complaints:
> >
>
> Fixed those. Same branch.
Thanks for the changes.
+ strlcpy(boot_cmdline, cmd
On 2015-11-10 at 08:22 "'Davide Libenzi' via Akaros"
wrote:
> The Linux recycle of __init memory comes from a time where memory was
> a bit tighter.
> Also, there are companies running Linux on devices where memory is
> very tight.
> We are talking about different things here though.
> I was not s
On 2015-11-10 at 08:30 "'Davide Libenzi' via Akaros"
wrote:
> On Tue, Nov 10, 2015 at 8:11 AM, Davide Libenzi
> wrote:
>
> > On Tue, Nov 10, 2015 at 7:59 AM, Barret Rhoden
> > wrote:
> >
> >> Two checkpatch complaints:
> >>
&g
Sorry for the hassle, but can you rerun this script from the latest
origin/staging? There's been a bunch of header changes, esp with the
VMM stuff, that prevents this from applying cleanly.
Thanks,
Barret
On 2015-10-29 at 06:28 "'Davide Libenzi' via Akaros"
wrote:
> https://github.com/brho/ak
Thanks, merged to staging at f30d87bf34f2..a759dfde3f64 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/f30d87bf34f2...a759dfde3f64
On 2015-11-09 at 18:34 "'Davide Libenzi' via Akaros"
wrote:
> https://github.com/brho/akaros/compare/master...
Thanks, merged to staging at 4402cbebfec6..f30d87bf34f2 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/4402cbebfec6...f30d87bf34f2
And I have a fancy command line now:
Boot Command Line: '/kernel Giraffes Inside'
Barret
On 2015-11
On 2015-11-10 at 08:46 "'Davide Libenzi' via Akaros"
wrote:
> there is no evil compiler worst case that is triggered by bad
> prediction. A branch can be arranged only in two ways. Without hints,
> it's random, with hints, you can make sure that you are doing better
> than random (50%).
I thought
On 2015-11-10 at 09:02 "'Davide Libenzi' via Akaros"
wrote:
> Same branch. Try how it looks now ...
Thanks. This merges, but there are a couple issues.
A minor one is that the headers in user/ and tests/ weren't included.
The big one is that this changes the kernel headers and actually
breaks
On 2015-11-10 at 11:12 "'Davide Libenzi' via Akaros"
wrote:
> Yep, it does.
The thing that wasn't compiling was the toolchain itself. I tried to
do that since some of the kern/include/ros/ header files were changed.
I'll try your latest.
Thanks,
Barret
--
You received this message because you
On 2015-11-10 at 11:19 "'Davide Libenzi' via Akaros"
wrote:
> Done.
> That branch builds for me, let me know otherwise.
> Yes, even in parlib, I had to manually fix one of those issues that
> you mentioned.
> There were a few on kern/.
Maybe I'm missing it, but it still doesn't build for me. I'm
omething.
barret
>
>
> On Tue, Nov 10, 2015 at 12:18 PM, Barret Rhoden
> wrote:
>
> > On 2015-11-10 at 11:19 "'Davide Libenzi' via Akaros"
> > wrote:
> > > Done.
> > > That branch builds for me, let me know otherwise.
> > &g
On 2015-11-10 at 12:22 "'Davide Libenzi' via Akaros"
wrote:
> Did the commit apply correctly?
> Yes, the #error is still there, but the ones including it, are
> correctly defining what that file wants.
looks like it still doesn't work for me. for example:
$ cd tools/compilers/gcc-glibc/
$ make
wrote:
> >
> >> Oh, wait, I did not run the xcc saga ...
> >>
> >>
> >> On Tue, Nov 10, 2015 at 1:53 PM, Barret Rhoden
> >> wrote:
> >>
> >>> On 2015-11-10 at 12:22 "'Davide Libenzi' via Akaros"
&g
On 2015-10-28 at 15:06 "'Davide Libenzi' via Akaros"
wrote:
> Since the previous one has not been done yet, this is a cumulative
> one:
>
> https://github.com/brho/akaros/compare/master...dlibenzi:profiler_dev_v2
>
>
> The following changes since commit
> 6f3723cd8f883260a78fdf411911d7469464caa
On 2015-11-11 at 08:48 Kevin Klues wrote:
> I have some git-hooks I wrote to perform checkpatch automatically on
> every commit. They haven't made their way back to master yet, but they
> are on my 'bootstrap' branch on github. Just copy these files into
> your $AKAROS_ROOT/.git folder to apply t
On 2015-10-28 at 15:06 "'Davide Libenzi' via Akaros"
wrote:
> Since the previous one has not been done yet, this is a cumulative
> one:
>
> https://github.com/brho/akaros/compare/master...dlibenzi:profiler_dev_v2
>
>
> The following changes since commit
> 6f3723cd8f883260a78fdf411911d7469464caa
Hi -
Overall, I'm a big fan of this patch set. But I do have a bunch of
concerns. Some minor, some bigger. See below.
Thanks,
Barret
On 2015-10-28 at 15:06 "'Davide Libenzi' via Akaros"
wrote:
> Since the previous one has not been done yet, this is a cumulative
> one:
>
> https://github.c
t; > > On Wed, Nov 11, 2015 at 10:06 AM, Davide Libenzi
> > > wrote:
> > >>
> > >> On Wed, Nov 11, 2015 at 9:07 AM, Barret Rhoden
> > >> wrote:
> > >>>
> > >>> These patches don't apply cleanly
On 2015-11-11 at 18:52 Kevin Klues wrote:
> Actually, looking a little closer, the fix is pretty easy:
>
> https://github.com/brho/akaros/compare/1ed63f9...a4a554e
>
> I'll defer to Barret to check if I missed anything.
> + int nvcores = max_vcores() ? max_vcores() : 1;
That's probably eno
On 2015-11-12 at 10:11 Edward Hyunkoo Jee wrote:
> It looks like the "master" branch has not been updated for a long
> time. Do we manually merge "staging" changes into "master"? How often?
I do it, and it's after changes sat on staging for a day or two.
> If we don't have an automated presubmit
On 2015-11-12 at 12:26 Kevin Klues wrote:
> Since staging was introduced, I basically ignore master and do all of
> my work off of staging instead.
yeah, thinking about it a bit, the odds of anyone actually catching a
bug on staging in the day or two a commit sits there is pretty low. so
far, i'v
On 2015-11-12 at 13:40 Kevin Klues wrote:
> I was actually meaning to advocate for keeping staging, but telling
> people to base their code off of that instead of master. With staging
> we can rollback and modify commits if necessary. With master we can't
> (or shouldn't at least).
i was thinking
On 2015-11-13 at 5:34 'Davide Libenzi' via Akaros wrote:
> I argue that strcat() as interface is bad enough done once, but done
> in a loop, by continuously throwing away the buffer length at every
> call, is even evil.
It might not be high performance, but from looking at the code it is
much mor
On 2015-11-12 at 14:00 'Davide Libenzi' via Akaros wrote:
> This function is gone on tip.
> Since this was v2, and v1 was never reviewed, you likely commented
> the v1 version.
I went off of:
> The following changes since commit
> 6f3723cd8f883260a78fdf411911d7469464caa5:
>
> Update file-posix
On 2015-11-13 at 9:03 'Davide Libenzi' via Akaros wrote:
> On Fri, Nov 13, 2015 at 8:32 AM, barret rhoden
> wrote:
>
> > > + for (i = 0; cmds[i]; i++) {
> > >> > + csize = strlen(cmds[i]);
> > >>
On 2015-11-13 at 09:22 "'Davide Libenzi' via Akaros"
wrote:
> I already changed it to use Dan's suggested strlcat() loop.
thanks.
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send
5 at 9:56 AM, Davide Libenzi
> wrote:
>
> > On Tue, Nov 10, 2015 at 6:42 AM, Barret Rhoden
> > wrote:
> >
> >> On 2015-11-09 at 17:35 "'Davide Libenzi' via Akaros"
> >> wrote:
> >> > OK, I fixed the strcpy to/from user code, in
Thanks, merged to master at 1ed63f9f8e25..70691bf40903 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/1ed63f9f8e25...70691bf40903
p.s.:
> are available in the git repository at:
>
> g...@github.com:GanShun/akaros.git
> 1facde8a0e93ab20ace
Thanks, merged to master at 70691bf40903..ba76ccc7aaef (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/70691bf40903...ba76ccc7aaef
On 2015-11-10 at 11:38 Edward Hyunkoo Jee
wrote:
>
> You can view, comment on, or merge this pull request onli
Thanks, merged to master at ba76ccc7aaef..2656cc9f5935 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/ba76ccc7aaef...2656cc9f5935
On 2015-11-11 at 03:13 ron minnich wrote:
> The following changes since commit
> a759dfde3f64ecc4e7f84d074ed69900
On 2015-11-12 at 09:30 Kevin Klues wrote:
> By the way, this is on a branch called
> klueska/always-init-vcore0s-mbox
that fixes davide's bug, but there are a host of others just like it,
due to the how userspace SCPs think they have a vcore, and max_vcores()
tells them how many.
i put together
This popped up if you ran Akaros on a single core machine. In that case, you'd
have 0 CG cores, which means the kernel gives you 0 vcores. However, SCPs
think they have one vcore. If a process runs at all, it needs to think it has
at least one vcore.
Rebuild busybox.
Signed-off-by: B
Thanks, merged to master at 2656cc9f5935..b0e11c6fa158 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/2656cc9f5935...b0e11c6fa158
On 2015-11-12 at 09:35 Kevin Klues wrote:
> The changes in this request can be viewed online at:
>
> https:/
Thanks, merged to master at b0e11c6fa158..a7bd47c1b299 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/b0e11c6fa158...a7bd47c1b299
On 2015-11-12 at 18:56 Kevin Klues wrote:
> The changes in this request can be viewed online at:
>
> https
On 2015-11-11 at 04:19 Kevin Klues wrote:
> I've finally gotten around to updating this branch.
looking at this now. btw, checkpatch mentioned a couple typos and such
(e.g. WARNING: 'fucntion' may be misspelled - perhaps 'function'?). I
can just touch that up, but I wanted to make sure your che
On 2015-11-13 at 13:08 Kevin Klues wrote:
> 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.
commits 5 and 9.
we talked about setting u
On 2015-11-13 at 13:04 Kevin Klues wrote:
> I thought about this, and it seems reasonable so long as we never use
> max_vocres() == 0 as a proxy for in_multi_mode() (i.e.
> __procinfo.is_mcp) anywhere. We may have done this in old code
> somewhere.
that'd be super buggy, since on any machine wit
This looks great. Some minor comments below.
I highly encourage other people to look at this patch set, since it's
an example of how to break a complex change up into understandable,
logical changes (a.k.a., a commit).
Thanks,
Barret
On 2015-11-11 at 04:19 Kevin Klues wrote:
> The following
Thanks, merged to master at a7bd47c1b299..bc87a54562ab (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/a7bd47c1b299...bc87a54562ab
On 2015-11-13 at 15:37 Barret Rhoden wrote:
> This popped up if you ran Akaros on a single core
On 2015-11-13 at 14:52 "'Davide Libenzi' via Akaros"
wrote:
> Here it is:
>
> https://github.com/dlibenzi/akaros/blob/user_memory_access_v2/kern/arch/riscv/uaccess.h
Ah, I see what the problem was.
These are the patches I see on your branch that differ from master
(basically the (FROM, TO] for
On 2015-11-14 at 05:29 "'Davide Libenzi' via Akaros"
wrote:
> Any news on this one?
Thanks, merged to master at bc87a54..bef4b38 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/bc87a54...bef4b38
yeah, i've been trying to avoid wo
On 2015-11-13 at 15:45 Kevin Klues wrote:
> Newest patchset, for reference:
>
> https://github.com/brho/akaros/compare/bc87a54...ab5b2c5
>
> git fetch g...@github.com:klueska/akaros sigpipe-support
Thanks, merged to master at bef4b38..1185c0a (from, to]
You can see the entire diff with 'git di
On 2015-11-16 at 15:37 Barret Rhoden wrote:
> These were blobs that Ron used for old virtualization debugging.
>
> Signed-off-by: Barret Rhoden
Thanks, merged to master at 1185c0a..2435991 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/
On 2015-10-29 at 14:32 Dan Cross wrote:
> [This is against a branch on /brho, but that's because it was
> in-flight before I created my own fork.]
>
> The following changes since commit
> 5025b06858b52dcd0a536e76f7da6e6e74c59589:
>
> Add the Inferno license to files we got from Inferno (2015-1
Hi -
On 2015-11-13 at 19:54 "'Davide Libenzi' via Akaros"
wrote:
> Coming to error(), should I always waserror() in my code, even if I
> have nothing to be undone?
> Because, that kinda defeats the exception-look-alike error model.
I think no. You only need a waserror if you need to cleanup if
On 2015-11-17 at 13:00 Edward Hyunkoo Jee
wrote:
>
> You can view, comment on, or merge this pull request online at:
>
> https://github.com/brho/akaros/pull/25
Can you send me a git URL and branch name for this? I imagine it's
your remote and this branch:
edjee/ak-kill-9pserver-001
manually.
Also, snc and kprof2perf leave blobs around that are tracked by git.
I fixed this myself with the following patch:
commit f622088961857a3153b8a3485d27e77dd3a77c4a
Author: Barret Rhoden
Date: Wed Nov 18 10:17:42 2015 -0800
Ignore build output for snc and kprof2perf in git
A
On 2015-11-17 at 17:02 Edward Hyunkoo Jee wrote:
> Yes, this is in branch ak-kill-9pserver-001 of repository
> http://github.com/edjee/akaros .
Thanks, merged to master at f622088..63c72d8 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/f622088
On 2015-11-19 at 17:44 "'Davide Libenzi' via Akaros"
wrote:
> If you prefer, you can hold on on this one, and do a bigger review
> later. I have a devarch_msr_perf branch forked off this one, where I
> am adding the counter overflow based tracing.
I already started on Friday (on the airplane). W
Hi -
On 2015-11-09 at 07:01 "'Davide Libenzi' via Akaros"
wrote:
> This adds the "msr" device to devarch, allowing userspace software
> (ie, CPU counters programming machinery) to interact with MSRs.
> I also cleaned up that file a bit, dropping a few things that were
> unused anywhere (there are
On 2015-11-19 at 20:52 "'Davide Libenzi' via Akaros"
wrote:
> IMO, all the local variable accessed within a waserror() return path,
> and (re)assigned after the waserror(), must be marked as volatile.
> Or bad things happen.
absolutely. the canonical example is in devwalk:
struct walkqid *devwa
On 2015-11-20 at 17:51 Kevin Klues wrote:
> I'd personally rather see an external framework that can be told how
> to build libs and apps on a per lib/app basis and install them into
> the akaros kfs via make magic. Something like:
>
> akaros-pkg-builder/
> ├── pkg/
> ├── sysroot/
> ├── .gitigno
On 2015-11-23 at 20:17 "'Davide Libenzi' via Akaros"
wrote:
> > > +void completion_wait(struct completion *comp)
> > > +{
> > > + cv_lock(&comp->cv);
> > > + if (comp->count > 0)
> > > + cv_wait(&comp->cv);
> >
> > This is fine as is.
> >
>
> This seems racy, in general. In th
On 2015-11-24 at 06:53 "'Davide Libenzi' via Akaros"
wrote:
> I added safe (exception table guarded) MSR read/write APIs.
awesome!
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send
Hi -
On 2015-11-12 at 12:34 Kevin Klues wrote:
> Updated with a new commit on top of the rest.
>
> The changes in this request can be viewed online at:
>
> https://github.com/brho/akaros/compare/1ed63f9...152eb22
>
> The following changes since commit
> 1ed63f9f8e25820f7eb217727d4ee88efe82
On 2015-11-24 at 08:21 "'Davide Libenzi' via Akaros"
wrote:
> > void completion_wait(struct completion *comp)
> > {
> > int8_t state;
> >
> > cv_lock_irqsave(&comp->cv, &state);
> > if (comp->count > 0) {
> > cv_wait_and_unlock(&comp->cv);
> > enable_irqsave(&state);
>
Our USB sticks expect a kernel named 'akaros' in /boot. The kernel can
be either a compressed kernel or uncompressed. I recommend compressed.
(Have your Makelocal's usb target depend on CMP_KERNEL_OBJ).
Signed-off-by: Barret Rhoden
---
Makelocal.template | 2 +-
1 file chang
If you want to use a USB keyboard, you'll need to enable this CONFIG.
It is disabled by default, since we usually use serial access and it is
a source of interference. Sometimes you want a keyboard for debugging.
Signed-off-by: Barret Rhoden
---
kern/arch/x86/Kconfig | 10 ++
kern
On 2015-11-24 at 11:38 "'Davide Libenzi' via Akaros"
wrote:
> I'll take care of that.
Thanks.
Also, we'll need to hook the exception fixups into the GPF handling
code:
/ $ cat \#arch/msr
HW TRAP frame at 0x80013ec7fad0 on core 0
rax 0x
rbx 0x
rcx 0x0
On 2015-11-24 at 09:08 Kevin Klues wrote:
> Fixed
Thanks, merged to master at 63c72d8a58dc..2a8a96f534b9 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/63c72d8a58dc...2a8a96f534b9
--
You received this message because you are subscribed to th
Hi -
On 2015-11-19 at 18:18 Kevin Klues wrote:
> The changes in this request can be viewed online at:
>
> https://github.com/brho/akaros/compare/63c72d8...6b9f50f
>
> The following changes since commit
> 63c72d8a58dc11457604164207075d6351e9c0bb:
>
> Create ak-kill-9pserver.sh that kills
On 2015-11-23 at 22:00 Dan Cross wrote:
> The following changes since commit
> 63c72d8a58dc11457604164207075d6351e9c0bb:
>
> Create ak-kill-9pserver.sh that kills ufs server (2015-11-18
> 10:37:28 -0800)
>
> are available in the git repository at:
>
> g...@github.com:dancrossnyc/akaros.git
On 2015-11-24 at 12:20 Kevin Klues wrote:
> >> + usec += kreq.tv_nsec ? (kreq.tv_nsec - 1)/1000 + 1 : 0;
> >
> > We have a helper for this, which I think does what you want:
> >
> > #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
>
> This only works in cases where we don't have to worry abo
On 2015-11-24 at 12:24 "'Davide Libenzi' via Akaros"
wrote:
> Should be all set now.
Awesome, thanks!
Thanks, merged to master at aecd50eb71c2..abe793d7c750 (from, to]
You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/aecd50eb71c2...abe793d7c750
--
You r
support for
dynamically adding entries.
Signed-off-by: Barret Rhoden
---
kern/drivers/dev/Kbuild | 1 +
kern/drivers/dev/Kconfig | 7 ++
kern/drivers/dev/vars.c | 183 +++
3 files changed, 191 insertions(+)
create mode 100644 kern/drivers/dev/vars.c
On 2015-11-24 at 14:10 Kevin Klues wrote:
> I'm curious if we don't want to expose the topology in the same way
> linux does in /proc so libraries like libnuma can compile and just
> work. I see the usefulness of this for variables in general, but I'm
> not sure num_cores should be here (or maybe i
On 2015-11-24 at 14:15 'Davide Libenzi' via Akaros wrote:
> This would have been a bit nicer IMO, if modules wanting to export
> variables, won't need to hack into another file.
> The macro, used locally in the module source files, would populate a
> given section with structs like:
>
> struct var
On 2015-11-24 at 14:05 Kevin Klues wrote:
> Only comment is on the name "pornstick", otherwise, looks good to me.
I can change that to usbstick.
>
> On Tue, Nov 24, 2015 at 11:40 AM, Barret Rhoden
> wrote:
> > Our USB sticks expect a kernel named 'akaros&
On 2015-11-24 at 14:40 Barret Rhoden wrote:
> Our USB sticks expect a kernel named 'akaros' in /boot. The kernel
> can be either a compressed kernel or uncompressed. I recommend
> compressed. (Have your Makelocal's usb target depend on
> CMP_KERNEL_OBJ).
On 2015-11-24 at 14:40 Barret Rhoden wrote:
> If you want to use a USB keyboard, you'll need to enable this CONFIG.
> It is disabled by default, since we usually use serial access and it
> is a source of interference. Sometimes you want a keyboard for
> debugging.
Thanks, me
Hi -
In this:
#define UT_ASSERT_M(message, test, ...)
\
do {
\
if (!(test)) {
\
char fmt[] = "
Hold on, I think I have a fix for it.
On 2015-11-25 at 16:38 Barret Rhoden wrote:
> Hi -
>
> In this:
>
> #define UT_ASSERT_M(message,
> test, ...) \ do
> {
On 2015-11-25 at 13:43 Kevin Klues wrote:
> 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...
Ah, so it's a cleanup before you return FALSE.
On 2015-11-25 at 16:49 Barret Rhoden wrote:
> Also, it looks like no one was using it either.
Other than this, which was using it indirectly:
user/utest/file-posix.c UT_ASSERT(ffd >= 0, close(dfd));
--
You received this message because you are subscribed to the Google
On 2015-11-25 at 13:50 Kevin Klues wrote:
> I am using it in my fork test which isn't pushed.
Cool, I'll just make UT_ASSERT_FMT().
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from
On 2015-11-24 at 17:02 Barret Rhoden wrote:
> With #vars, you can specify certain global variables, such as
> num_cores, to be exposed to userspace.
I opted for a mix of some of the ideas in this thread. Here's the
basics:
* #vars device, exports read access to select kerne
On 2015-11-25 at 17:39 Dan Cross wrote:
> The following changes since commit
> 22e5a17da08e101bf9c4c60cabac6750739b849b:
>
> x86: Provide an option to enable legacy USB (2015-11-25 09:44:48
> -0500)
>
> are available in the git repository at:
>
> g...@github.com:dancrossnyc/akaros.git reall
On 2015-11-27 at 8:24 'Davide Libenzi' via Akaros wrote:
> I don't think I need a clone thing, once agreed I can use the
> read+write transaction model on the perfctl device.
Is there just one perfctl file that you'd be operating on? I thought
the benefit of the clone was that you could create s
On 2015-11-27 at 9:27 'Davide Libenzi' via Akaros wrote:
> I assume that, like in every other OS, if two processes (or even the
> same process twice) open a given file, there will be a separate
> struct chan* for each, right?
Yes.
> If so, I don't need clone.
Cool. Makes things simpler then.
On 2015-11-28 at 7:19 'Davide Libenzi' via Akaros wrote:
> These interfaces though, are not exposed to userspace, so I will have
> to move them into a dedicated ros/ file, I guess?
That's fine. In the long term, I'd like to make these interfaces
protobufs, such that the .proto is in ros/, and bo
On 2015-11-28 at 15:27 ron minnich wrote:
> I kind of agree with Davide that a clone file is not needed. You can
> differentiate sessions in the chan you get from open.
Totally. The clone style that #ip uses is only necessary if you
actually need the sub-directory (e.g. /net/tcp/5/*). If all you
1 - 100 of 1017 matches
Mail list logo
