On 2015-12-15 at 12:58 "'Davide Libenzi' via Akaros"
<[email protected]> wrote:
> Sorry, I applied that to the head of that file.
> Now it is kind of a mess to apply only those to an older commit, when
> the changes have been merged into that one.
> Do you have any recipe?
Not a one liner. What I usually to split up a commit is this:
$ git rebase -i some-commit-far-back-enough
pick the commit you want to split. change it from "pick" to "edit".
take note of the commit hash (will need it later).
git will stop there, then you can do whatever you want to that commit.
at that point i do:
$ git reset HEAD^
(pops off the commit.)
$ git add -p
(selectively add back in all of the things that should have been in
that original commit, but not the things you don't want)
$ git commit -c HASH_FROM_THE_COMMIT_ORIGINALLY
then add everything else from that commit to a WIP commit:
$ git add -p
$ git commit -m WIP-fixing-whatever
Then finish the git rebase:
$ git rebase --continue
At this point, all that did was split up a commit into two commits.
You could do whatever you want during that 'edit' phase of the rebase,
including making more commits.
Then you do another rebase -i, and move the WIP-fixing-whatever to the
right spot in the history.
If it turns out to be too much of a pain, then don't worry. But try to
catch it next time. =)
> > > #include <sys/types.h>
> > >
> > > +#define PROF_DOM_SHIFT (8 * sizeof(uint64_t) - 4)
> > > +#define PROF_INFO_MASK (((uint64_t) 1 << PROF_DOM_SHIFT) - 1)
> >
> > This is a little confusing. The DOM shift is just 60, right? Is
> > that value special (hence the 8 * sizeof - 4)?
> >
>
> Why confusing? It just leaves 4 bits for domain.
I was a little confused about the math computing the DOM_SHIFT. I see
that it's just 60, with 4 bits for dom. I was wondering if the
sizeof(u64) was trying to save enough space in the INFO_MASK or
something. Feel free to leave it as is.
> > Subject for a future patch: are these structures copied in native
> > endianness, or in an endian-independent format?
> >
>
> They are machine dependent (they assume machine).
> We could make them independent, but I am not sure it is worth the
> effort at this time.
Probably not. =)
> > > void profiler_notify_new_process(struct proc *p)
> > > {
> > > if (kref_get_not_zero(&profiler_kref, 1)) {
> > > - if (profiler_percpu_ctx && tracing &&
> > > p->binary_path)
> > > + if (profiler_percpu_ctx && p->binary_path)
> > > profiler_push_new_process(p);
> > > kref_put(&profiler_kref);
> > > }
> >
> > So now we're emitting trace info on all mmaps and process creation,
> > even if the profiler is turned off?
> >
>
> No. If the profiler is not started, percpu_ctx is NULL.
Ah, whoops. I missed free_cpu_buffers() being called whenever we stop
profiling. =)
> > > From d2e4bae5a18d21205bf5de243450794a91674386 Mon Sep 17 00:00:00
> > > 2001 From: Davide Libenzi <[email protected]>
> > > Date: Sun, 13 Dec 2015 13:58:20 -0800
> > > Subject: Emit build information file into KFS /etc/build.info
> >
> > > +KERNEL_ELF_PATH=$(abspath $(KERNEL_OBJ))-64b
> >
> > This -64b is arch specific. We'll want to get this variable from
> > the arch/Makefile.
> >
>
> How?
KERNEL_ELF_PATH can be defined in each arch's Makefile, which gets
included into the top-level Makefile. The existence of the -64b
version of the file is an x86 thing. At least for now. (It's created
by this:
# Need to change the format to 32 bit, to trick multiboot/grub1 into loading
ARCH_POST_LINK_CMD = cp $@ $@-64b; $(OBJCOPY) -I elf64-x86-64 -O elf32-i386 $@
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 it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
