akaros.cs.berkeley.edu Git - akaros.git/rss - user/vmm/util.c historyhttp://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=history;f=user/vmm/util.c
AkarosenBarret Rhodenstatic/git-logo.pngakaros.cs.berkeley.edu Git - akaros.git/rss - user/vmm/util.c historyhttp://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=history;f=user/vmm/util.c
Thu, 11 Apr 2019 21:13:44 +0000Thu, 11 Apr 2019 21:13:44 +0000gitweb v.2.7.4/2.7.4parlib: have 2LS libraries #include parlib/stdio.hBarret Rhoden <brho@cs.berkeley.edu>Thu, 11 Apr 2019 21:06:06 +0000http://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=commitdiff;h=ba3acab96e99ff6c3cd2dd5d147928be927a4ceehttp://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=commitdiff;h=ba3acab96e99ff6c3cd2dd5d147928be927a4cee
parlib: have 2LS libraries #include parlib/stdio.h
parlib: have 2LS libraries #include parlib/stdio.h
For painful reasons, if you call any functions related to printf from
vcore context or from a uthread with notifs disabled, you need to use
our special fprintf macros. You get those via parlib/stdio.h, which
also #includes the real stdio.h.
Most code that this could happen to come from parlib, pthread, or vmm.
This commit just changes all of their headers to include parlib/stdio.h.
This is far from the best approach, but it stops the bleeding.
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>

]]>
Treat tabs as having eight spaces instead of fourBarret Rhoden <brho@cs.berkeley.edu>Tue, 12 Mar 2019 23:41:50 +0000http://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=commitdiff;h=e2e76c34b4eb027eec44bf0ab81523c4359aa6a3http://akaros.cs.berkeley.edu/gitweb/?p=akaros.git;a=commitdiff;h=e2e76c34b4eb027eec44bf0ab81523c4359aa6a3
Treat tabs as having eight spaces instead of four
Treat tabs as having eight spaces instead of four
For whatever bad reason, we chose to treat tabs as four spaces instead
of eight. e.g. in vim, tabstop=4.
That's a huge pain - both when dealing with other tools and when
switching between projects. I don't particularly like having
per-project vim settings and whatnot. Plus, that's a bit harder for
other people who look at our code and have their vim/emacs set to 8
space tabs.
I had regretted that for a long time, but I didn't want to make the
change for two reasons:
1) With other people working on the project, changes of this sort can
lead to merge conflicts. Since I'm the only one working on it, for the
most part, this isn't a concern.
2) The bigger reason is that major reformatting changes break git blame.
However, there are tools that can ignore commits when running git blame.
Chromium has git hyper-blame. I thought that feature ought to be baked
into git, so I have a patchset out for git to do so. Either way, I'll
either have my own patched git or the feature will get merged. In a
future commit, I'll have instructions for how to use that feature.
A lot of our files didn't need too much attention, due to our old
"spaces for formatting" policy. I didn't change those to use tabs
instead of spaces for the formatting either. I expect newer code will
just do whatever people's editors do. I didn't want to change more
lines than were needed, and the code looks the same either way.
The biggest offenders were indented comments. Structs with
column-aligned members needed some work too. I did most of that stuff
manually, since the tools do a mediocre job.
Since I was making changes, I also fixed up the switch-case indenting:
don't do an extra level of indentation for the case keywords. Doing
this now actually helped with the 8-space tab change, since switch
statements got a few spaces to work with.
A few of the kernel's C files were so badly messed up that I just used
clang-format on them. Same for Plan 9 files that had been
clang-formatted before and hadn't been heavily modified by us.
Clang-format caused a few problems with its "alphabetized headers"
policy. That was fun.
Higher-quality (subjectively) code didn't need as much work as older,
poorer code. Specifically, code with way too many levels of indentation
looks even worse than before - that's actually a benefit of 8-space
tabs: it tells you when your code is bad. A lot of that older code
needs a more serious refactoring, which this commit does not do.
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>