akaros.git
4 years agoChange all references of num_cpus -> num_cores
Kevin Klues [Tue, 21 Jul 2015 03:10:13 +0000 (20:10 -0700)]
Change all references of num_cpus -> num_cores

As we start to integrate more sophisticated cputopology information into
the kernel, we will need to be careful about our naming of these
variables.  CPUs are different than cores (on a hyperthreaded machine,
there are at least 2 cores per cpu), so we need to be more consistent
with our naming to avoid confusion.  Moreover, as we add more
cputopology information, we will likey want to know the actual num_cpus
in addition to the num_cores, so we want to make sure we have the right
semantics for these variables before this change is introduced.

4 years agoRemove env_entry from struct proc
Barret Rhoden [Wed, 22 Jul 2015 19:32:44 +0000 (15:32 -0400)]
Remove env_entry from struct proc

No need for it, now that the actual entry point is just set in elf.c and
that the vcore entry point is set in VCPD.

4 years agoRename transition_stack -> vcore_stack (XCC)
Barret Rhoden [Wed, 22 Jul 2015 19:30:28 +0000 (15:30 -0400)]
Rename transition_stack -> vcore_stack (XCC)

The name 'transition' predates vcores.  Might as well keep the
vcore_stack in line with vcore_entry and vcore_tls_desc.

Reinstall your kernel headers.

4 years agoAdd vcore_entry to vcpd (XCC) (2/2)
Kevin Klues [Sat, 18 Jul 2015 17:01:26 +0000 (10:01 -0700)]
Add vcore_entry to vcpd (XCC) (2/2)

In this commit we finalize the migration of vcore_entry into the vcpd.
As part of this, a significant amount of cleanup has been done.  In
addition to removing all system dependent startup code from glibc, we
also now only initialize __vcore_id, __vcore_context, and only call
__ctype_init() once when a vcore's TLS is first allocated.

Currently, the vcore entry point is set to point to a static function
called __kernel_vcore_entry, whose sole job is to grab the vcore_id of
the vcore passed in by the kernel, and set up the vcore's TLS by
extracting it from the vcpd for that vcore.  It then calls the real
vcore_entry of the application.  In the future, if we decide to
standardize on the kernel setting up our vcore TLS for us (as it does
for x86_64), then this level of indirection can be avoided.

Although not currenlty utilized, one nice property of this approach (in
addition to removing our reliance on making _start reentrant), is that
different vcore_entry() points can be set up for different vcores,
potentially providing a fast path for critical code running on those
vcores that doesn't need to run through the standard vcore_entry()
sequence.  Such functionality may provie useful in the future.

[brho: moved vcore_entry's in VCPD adjacent to stack and tls_desc, added
comment and __vcore_entry = TRUE in __kernel_vcore_entry() ]

4 years agoAdd vcore_entry to vcpd (XCC) (1/2)
Kevin Klues [Sat, 18 Jul 2015 16:45:21 +0000 (09:45 -0700)]
Add vcore_entry to vcpd (XCC) (1/2)

These next two commits finalize the migration of setting up a vcore
specific entry point in vcpd instead of always reentering userspace via
the _start function. Having our _start function be reentrant has always
been a hack, and this patch finally removes all remnants of system dependant
process entry code in glibc. We now only enter a process via the _start
function provided by sysdeps/x86_64, and there is no custom
initialization code forced into crt1.o via init.c. All startup code
now runs properly inside the vcore_lib_init() constructor function from
parlib.

Logically, these two commits are part of a single patch
(i.e. the xcc will not compile until both of them have been applied),
but it is clearer if I break them up into separate commits.

In this first commit, I simply export our tls related functions from
glibc through stdlib instead of bundling them in our init.c file.
Previously, we (hackishly) #included tls.c inside of init.c in order to
make its functions available to __libc_vcore_entry() (this was necessary
because init.c is part of crt1.o and simply including tls.c as part of stdlib
is not sufficient to give init.c access to its functions). In the
following commit we do away with init.c completely, so this is no longer
an issue.

4 years agoExport __ctype_init out of glibc
Kevin Klues [Sat, 18 Jul 2015 16:33:07 +0000 (09:33 -0700)]
Export __ctype_init out of glibc

Normally this function is not exported by glibc because all threading
and TLS related operations are typically confined to glibc.  Since we do
all of our threading and TLS management in parlib, we need to export
__ctype_init so it can be properly called in any of the newly
initialized TLSs we create.  This functionality is not currently used,
but will be in a future commit.

4 years agoRename vcore-tls.{h,c} to tls.{h,c}
Kevin Klues [Sat, 18 Jul 2015 16:26:06 +0000 (09:26 -0700)]
Rename vcore-tls.{h,c} to tls.{h,c}

TLS operations are not just for vcores anymore (and haven't been fore a
very long time).

[brho: fixed the #define name for sys/tls.h ]

4 years agoRemove vcoreid from get/set_tls_desc
Kevin Klues [Sat, 18 Jul 2015 15:56:37 +0000 (08:56 -0700)]
Remove vcoreid from get/set_tls_desc

The presence of vcoreid as a parameter to these functions is remnants of
the old i386 way of using the LDT for TLS management.  Moreover, we only
really passed vcoreid in the first place because we were trying to avoid
a call to sys_getvcoreid() (a very antiquated way of getting the vcore
id).  These were the days before we standardized on *always* having
__vcoreid available in everyone's TLS (including uthreads).

Nowadays passing this parameter is completely unnecessary (and actually
meaningless on x86_64 and riscv). It is actually just ignored if you
pass any value in at all. Removing it for these systems is completely
benign. For i386 (which we don't even really support anymore), it is
sufficient to just call vcore_id() internally and use that to index into
the proper ldt.  In the (near) future, we should consider removing i386
support completely. I leave it here now for reference.

This change has been possible for quite some time, but was finally
motivated by the desire to get the tls_desc of the main thread in an
early SCP before any notion of vcores or vcore management has been set
up. In a future commit, we will use this to temporarily save off the
main thread's tls_desc during vcore initialization itself.
It would probably have been OK to just assume vcoreid 0 for the main
thread (especially since passing it on x86_64 was completely benign),
but it is an unecessary parameter to begin with, and better to just
clean things up the right way as we move forward.

[brho: added a void to a func definition ]

4 years agoUse BUILD_ERROR_DELIMITER not hard-coded constant
Kevin Klues [Sat, 18 Jul 2015 17:59:24 +0000 (10:59 -0700)]
Use BUILD_ERROR_DELIMITER not hard-coded constant

4 years agoExplicity cast to char*
Kevin Klues [Sat, 18 Jul 2015 17:13:51 +0000 (10:13 -0700)]
Explicity cast to char*

When you subtract 2 pointers you end up with a long, so you need to
explicity cast back to the proper pointer type to avoid a warning.

4 years agoAdds instructions for using the profiler
Barret Rhoden [Wed, 15 Jul 2015 21:13:28 +0000 (17:13 -0400)]
Adds instructions for using the profiler

4 years agoudelay_sched() -> kthread_usleep()
Barret Rhoden [Wed, 15 Jul 2015 19:09:09 +0000 (15:09 -0400)]
udelay_sched() -> kthread_usleep()

Both functions do the same thing, but were created at different times.
Only one can survive!  kthread_usleep() is a little more clear than
udelay_sched(), hence the change.

4 years agoPthread sched_ops cleanup
Barret Rhoden [Tue, 14 Jul 2015 23:02:17 +0000 (19:02 -0400)]
Pthread sched_ops cleanup

Using the explicit style of assignment, instead of the implicit,
order-based style.  This way, we can handle changes in the sched_ops
structure more easily, as well as be more explicit about which ops are
which.

Also, this makes all the ops static: there's no reason for them to be
otherwise.

This also removes the unused preempt_pending and spawn_thread callbacks.
If we want them, we should build them, and don't install fake sched_ops.
For instance, event code will complain if you request a thread for an
event queue but don't have a sched op.  It won't complain if the sched
op is a noop.

4 years agoFixes MCP check in UCQ
Barret Rhoden [Tue, 14 Jul 2015 22:54:58 +0000 (18:54 -0400)]
Fixes MCP check in UCQ

This was just for emitting a warning, but it should have been using the
helper.

4 years agoCleans up the kernel's view of SCPs
Barret Rhoden [Tue, 14 Jul 2015 22:49:45 +0000 (18:49 -0400)]
Cleans up the kernel's view of SCPs

For a number of years, the kernel has used Vcore 0 as the SCPs fake
vcore.  This is now official: no more TODO VC#!

While documenting this, I noticed a couple places where we were not
consistent with our treatment of VC 0.  For instance, SCPs didn't always
have VC 0 unmapped (ksched tick, proc_destroy()).  Likewise, some places
unmapped, but didn't toggle the seqctr (sys_exec()).

While none of those things mattered for the SCPs, since there is no
guarantee that the seqctr will be toggled, and once an SCP isn't
running, it's mapping probably doesn't matter much, it still needed to
be consistent.

4 years agoKernel reflects unhandled faults to SCPs
Barret Rhoden [Mon, 13 Jul 2015 22:10:28 +0000 (18:10 -0400)]
Kernel reflects unhandled faults to SCPs

The lack of verbosity from userspace can be a little difficult.  Just a
trapframe isn't always enough.  To fix this, you can turn on printx to
have the kernel spew whatever info it has for any malignant faults
(non-benign).  Benign faults are those that occur during normal
operation.

At this point, the kernel shouldn't care at all if an SCP uses a 2LS or
not.  Outside proc code, the major places that care about SCP vs MCP are
the scheduler, event code (just spam messages to VC 0), and the page
fault handler (helps out SCPs).

The latter point means that SCPs with 2LSs won't actually get their
VMR-backed page faults reflected - instead the kernel just blocks them.
Considering how there is no guarantee to SCPs that they retain their
core during blocking events, I'm okay with this for now.

The alternative is to have a more capable __scp_thread_refl_fault()
handler and slightly worse performance for all processes before they
turn into MCPs (more expensive PFs when they are initializing).

4 years agoCs is a multithreaded SCP
Barret Rhoden [Mon, 13 Jul 2015 19:49:20 +0000 (15:49 -0400)]
Cs is a multithreaded SCP

This allows us to make requests, such as for www.google.com, without
deadlocking.  The deadlock was caused by cs opening /net/dns.  Cs has a
mount at /net.  The kernel would ask that mount to do a walk to ./dns.
Cs, when single threaded, would never get the request from the kernel.

Incidentally, this shows how easily the user can screw up their
namespace.  Any program that mounts into the namespace can perform a DoS
on anyone else looking up in that namespace.  The kthread in the kernel
would be attributed to whoever did the request, too, and not to the
daemon.  The moral is that mounters are somewhat privileged.

The other rule is that any program that serves a mount must always be
responsive to mount requests; either never block in servicing requests
or be multithreaded.

4 years agoAllow SCPs to run a pthread 2LS
Barret Rhoden [Wed, 15 Jul 2015 19:47:58 +0000 (15:47 -0400)]
Allow SCPs to run a pthread 2LS

The application must set parlib_wants_to_be_mcp to FALSE before calling
into the pthread library.

I used can_adjust_vcores to turn off vcore_request, but we still want to
yield.  Being an MCP isn't the same as adjusting your vcores.  I used
can_adjust to limit the impact of the SCP capabilities on the normal 2LS
operation - now it only involves a slight check when we are yielding and
have no work to do.

SCP code should be able to call vcore_yield() as well as sys_yield().
vcore_yield() has protections to keep from missing messages.  SCPs don't
need that, since the kernel just blasts the message.  sys_yield
(proc_yield() in the kernel) won't let the SCP sleep when there is a
notif pending, so we shouldn't need to go through all of those extra
steps.

4 years agoSCPs can be 2LSs
Barret Rhoden [Mon, 13 Jul 2015 19:44:11 +0000 (15:44 -0400)]
SCPs can be 2LSs

Ever since SCPs had vcore context, we were pretty close to having them
run a 2LS.  The main thing is to not turn into an MCP and to not make
vcore requests (even though that is currently harmless).

In the current instatiation, deciding to be an MCP must be done early
on, before calling uthread_mcp_init.  There are some races associated
with upgrading from an SCP to an MCP on the fly, after the 2LS has been
running.  Until we have a compelling case for that, we won't support it.

For now, the default is that processes with 2LSs will be MCPs.  In the
future, we'll probably change that, such that environment variables and
compile time options can control whether or not a process is an MCP or
SCP, possibly with SCP by default.

This variable exists in parlib.c.  Other control variables that are part
of Parlib's API will go here as well.  These are things that
applications can expect to exist (until the API changes!).

4 years agoFixes up syscall_blockon functions (XCC)
Barret Rhoden [Mon, 13 Jul 2015 18:19:41 +0000 (14:19 -0400)]
Fixes up syscall_blockon functions (XCC)

Our old blockon functions had three problems:

- MCP blockon was assuming MCP == 2LS.

- SCPs in VC context that blocked would clear notif disabled!  The
  danger here is that the vcore's stack would get clobbered.  To have
this happen, you'd need to have an SCP that dropped into vcore context
and issued a blocking syscall, and then receive a notif.

- Excessive SCP notifies, due to using the early blockon in glibc.  For
  instance, any SCP that had a blocking syscall would issue the call, a
yield, and then a self-notify.  The notify was due to us manually
disabling/enabling notifs.

This commit fixes the old early blockon (was scp_blockon) and only uses
it for early SCPs (pre-vcore context).  It updates the uthread blockon
(was mcp_blockon) to support *all* SCPs, with or without 2LSs, and MCPs.

Note that the early blockon is basically like vcore context, and it is
used for vcore contexts that issued blocking syscalls for SCPs in any
state (2LS or not).  Likewise, before parlib initializes, the kernel
knows the process can't handle vcore context, and handles it
accordingly.

Rebuild glibc.

4 years agouth: Track thread0 in uthread.c
Barret Rhoden [Mon, 13 Jul 2015 18:08:31 +0000 (14:08 -0400)]
uth: Track thread0 in uthread.c

Needed to have SCPs with no 2LS block uthreads on syscalls properly.
The code prior to this always assumes that current_uthread is set, and
it is thread0.  It'll be easier to reuse parts of uthread for
non-full-2LS SCPs if we can clear current_uthread on occasion.  Still,
in these cases we only have one uthread: thread0.

4 years agouth: Use a thread0 sched ops for SCPs without 2LSs
Barret Rhoden [Mon, 13 Jul 2015 21:39:36 +0000 (17:39 -0400)]
uth: Use a thread0 sched ops for SCPs without 2LSs

Instead of assuming the lack of a sched_entry means we are an SCP, we
can use the default sched ops still for a "thread0" scheduler.  All
processes, even those that link in a real 2LS capable of handling MCPs
or other things, will use this scheduler for at least a brief period.

As far as the functionality, goes, this changes nothing.  We still
insist on running current_uthread.  But this also removes one runtime
branch from the common-case code!

4 years agoRemoves some old asserts from parlib/2LS init
Barret Rhoden [Fri, 10 Jul 2015 20:50:14 +0000 (16:50 -0400)]
Removes some old asserts from parlib/2LS init

We know the constructors are running exactly once before any other code.

4 years agoEnable/disable notifs for SCPs
Barret Rhoden [Fri, 10 Jul 2015 20:33:49 +0000 (16:33 -0400)]
Enable/disable notifs for SCPs

The intent of the checks for in_multi_mode() was really checking for
whether or not we *have* vcore context.  Since even SCPs have vcore
context (vcore 0) and the kernel can drop an SCP into vcore context
when an event arrives (a "notification"), then even SCPs need to worry
about disabling and enabling notifs.

Note that there is a brief time before vcore 0's context is set up for
the SCPs, which occurs in the vcore_lib_init() constructor.  That's all
before anything from parlib should be called, including the functions
changed here.

4 years agoUpdates get_html to the webserver's new IP
Barret Rhoden [Wed, 8 Jul 2015 17:31:26 +0000 (13:31 -0400)]
Updates get_html to the webserver's new IP

Still don't have DNS working.  =(

4 years agoAdd target to easily re-install the akaros headers
Kevin Klues [Wed, 15 Jul 2015 05:15:27 +0000 (22:15 -0700)]
Add target to easily re-install the akaros headers

4 years agoAdd 'xcc-upgrade' and 'xcc-upgrade-from-scratch'
Kevin Klues [Wed, 15 Jul 2015 01:37:33 +0000 (18:37 -0700)]
Add 'xcc-upgrade' and 'xcc-upgrade-from-scratch'

These new top level makefile targets have been added to make it easier
to rebuild things after a xcc upgrade. These targets will rebuild your
cross compiler as well as rebuild akaros, and all embedded user-land
stuff including busybox. It will also install this all into kfs for you.

4 years agoAdd targets to install/clean bundled apps
Kevin Klues [Wed, 15 Jul 2015 16:36:23 +0000 (09:36 -0700)]
Add targets to install/clean bundled apps

Right now these just clean / install busybox, but we can add more in the
future as we bundle them.

4 years agoAdd useful XCC targets to top level makefile
Kevin Klues [Wed, 15 Jul 2015 01:00:53 +0000 (18:00 -0700)]
Add useful XCC targets to top level makefile

All of the valid XCC subcmd and clean targets are automatically made
available for the current ARCH via calls to 'make xcc-*'. Tab complete
them out to see the full list.  The standalone 'xcc' target will build
the cross compiler for the configured architecture and install it (e.g.
the same as running 'make x86_64', etc. down in the xcc directory as we
used to have to do).

One thing to point out here is the settings we have to mess with for the
environment passed to our recursive make calls. All of the exports in
the top level Makefile, mess with the settings of the xcc Makefile (and
busybox's Makefile) when we do a recursive make.  The two lines:

export_parent_env := $(shell export | sed 's/$$/;/')
clear_current_env := for c in $$(env | cut -d '=' -f 1); do unset $$c; done;

make it so that later on I can just clear out the current environment
and restore the environment of the parent just before making my
recursive make calls. It's easier than manually going through and
'unexporting' everything that the Makefile exported. It also keeps us
from having to keep these exports in sync with unexporting them
somewhere else.  At the end of the day, it boils down to the fact that
our xcc make wants the environment set up in our shell, not the one set
up in the top level makefile. Having these commands available makes it
easier to set this up.

I have also added a 'make_as_parent' define so that we can more easily
execute local make targets as if they were invoked from the parent.

4 years agoPipe $(OBJDUMP) output to /dev/null to avoid error
Kevin Klues [Wed, 15 Jul 2015 00:32:37 +0000 (17:32 -0700)]
Pipe $(OBJDUMP) output to /dev/null to avoid error

We do this in other places, and without it we get some benign errors if
we don't have a valid cross compiler installed for our architecture. We
fail out gracefully later on.

4 years agoUnexport LD_LIBARY_PATH before building xcc
Kevin Klues [Wed, 15 Jul 2015 14:48:51 +0000 (07:48 -0700)]
Unexport LD_LIBARY_PATH before building xcc

If you happen to have this set in your environment, glibc will error out
when building.  I've been encountering this for years and just manually
unexporting it in my shell before invoking make.  It makes sense to just
unset it explciitly here though.

4 years agoMake XCC uninstall robust to failures
Kevin Klues [Wed, 15 Jul 2015 00:31:27 +0000 (17:31 -0700)]
Make XCC uninstall robust to failures

4 years agoAdd the 'check-env' target to the XCC Makefile
Kevin Klues [Tue, 14 Jul 2015 21:49:05 +0000 (14:49 -0700)]
Add the 'check-env' target to the XCC Makefile

4 years agoAllow multiple make errors to be triggered at once
Kevin Klues [Tue, 14 Jul 2015 21:48:27 +0000 (14:48 -0700)]
Allow multiple make errors to be triggered at once

4 years agoXCC -> cross compiler, CXX -> C++
Kevin Klues [Wed, 15 Jul 2015 06:17:10 +0000 (23:17 -0700)]
XCC -> cross compiler, CXX -> C++

4 years agoFix typo in XCC Makefile error message output
Kevin Klues [Tue, 14 Jul 2015 21:45:09 +0000 (14:45 -0700)]
Fix typo in XCC Makefile error message output

4 years agoFinalize arg, env, aux migration (3/3) (CXX) (BB)
Kevin Klues [Mon, 13 Jul 2015 06:41:52 +0000 (23:41 -0700)]
Finalize arg, env, aux migration (3/3) (CXX) (BB)

Remove all traces of procinfo->argp and procinfo->argbuf from the kernel
and the cooresponding procinfo.h header file.

4 years agoFinalize arg, env, aux migration (2/3) (CXX) (BB)
Kevin Klues [Mon, 13 Jul 2015 06:31:12 +0000 (23:31 -0700)]
Finalize arg, env, aux migration (2/3) (CXX) (BB)

In this commit I remove a few sysdep files that we no longer need to
specialize anymore. However, because Akaros needs to have the ability to
reenter the _start function mutliple times, it is impossible to do away
with all sysdeps on these low level interfaces.

The true system dependent stuff has now been isolated in a file called
init.c in sysdeps/akaros (this name is required in order to get it to
link in with crt1.o).  It now introduces a new function called
__libc_vcore_entry(), which handles all the code necessary to deal with
our reentrant _start() function.  Our system dependant _start() function
simply calls out to __libc_vcore_entry() and then jumps to the
_real_start(), as defined by the current architecture (currently only
x86_64).

By becoming compliant with the SYSV ABI all of the code dealing with
unpacking our args, env, and auxv data from procinfo is now unnecessary.

4 years agoFinalize arg, env, aux migration (1/3) (CXX) (BB)
Kevin Klues [Mon, 13 Jul 2015 06:23:20 +0000 (23:23 -0700)]
Finalize arg, env, aux migration (1/3) (CXX) (BB)

The next 3 commits break up the last steps of migrating our arg, env,
and aux vectors to be passed on the stack instead of in procinfo.  This
now makes us compatible with the SYSV ABI, and thus much less reliant on
sysdep customizations in glibc. (of which we probably missed a bunch we
didn't even realize before).

This commit focuses on the final changes to the kernel internals that
allow us to properly pass this information on the stack. The
populate_stack() function in elf.c now properly fills out the chunk of
the stack responsible for passing this information instead of populating
procinfo. We also needed to fix some stack alignment stuff in
proc_ctx_init() now that we are relying on the stack to contain specific
content. The comments in process64.c outline what this change was.

4 years agoOne step closer to argv/envp/auxv on the stack
Kevin Klues [Sun, 12 Jul 2015 19:31:10 +0000 (12:31 -0700)]
One step closer to argv/envp/auxv on the stack

I've now rearranged load_elf to call out to a function called
populate_stack(), which will fill in the argc, envp, and auxv
information in the appropriate places on the stack. For now it still
fills in procinfo, but I've rewritten how this is done so that it makes
memcpy_to_user() calls to (UINFO)->argp and (UINFO)->argbuf instead of
writing to the kernel mapping for p->procinfo->argp and
p->procinfo->argbuf. This mimics how I plan to copy data onto the user
stack in a subsequent commit.

To make this work, I've had to temporarily modify the memcpy_to_user()
call to accept writes to memory that is mapped as 'user-read-only'. This
was necessary since procinfo is mapped in in this way.  Once I start
writing to the stack, this will not be an issue, and this change can be
reverted.

4 years agosys_exec and sys_proc_create now use argenv (XCC)
Kevin Klues [Sun, 12 Jul 2015 02:03:38 +0000 (19:03 -0700)]
sys_exec and sys_proc_create now use argenv (XCC)

These syscalls now take an argenv pointer and it's length instead of a
pointer to a procinfo struct with the arg and env stuff embedded in it.

When these syscalls are issued, the kernel first copies the argenv
structure to kernel memory, verifies internal consistency of all
pointers, and unpacks it into argc, envc, argv, and envp variables for
further processing. It then passes these values to a new implementation
of load_elf, who is now responsible for making sure these values end up
in the right place for the new process.  Eventually this will be on it's
stack at the locations defined by the SYSV ABI.  For now, it just copies
them into procinfo since taht is where existing code expects it to be
when popping into user space.

The main purpose of this commit was to make sure that this new method of
passing arguments and environment is going to work, moving forward. The
next step is to modify where these values are placed (i.e. on the new
processes stack), and then update the low levels of user-space to
account for this change.

4 years agoProtect against NULL pointer to set_progname
Kevin Klues [Sat, 11 Jul 2015 20:32:05 +0000 (13:32 -0700)]
Protect against NULL pointer to set_progname

If name is NULL, we set the name to DEFAULT_PROGNAME. Right now
DEFAULT_PROGNAME is just "".  We could consider adding a default name
such as "unknown" or something similar, but this would conflict with any
valid programs with that same name...

4 years agoAdd specs for argenv interface with the kernel
Kevin Klues [Sat, 11 Jul 2015 00:02:40 +0000 (17:02 -0700)]
Add specs for argenv interface with the kernel

The argenv struct defines the layout of the argenv pointer serialized by
the user function serialized_argv_envp.  This will become important as
we move towards passing this pointer to sys_proc_create() and
sys_exec().

4 years agoAdd serialization for syscall args (XCC)
Kevin Klues [Fri, 10 Jul 2015 08:39:38 +0000 (01:39 -0700)]
Add serialization for syscall args (XCC)

It is useful to be able to serialize data into a single buffer for
passing data to the kernel.  The first use case of this is serializing
the data pointed to by argv and envp along with their pointers.
Currently, we use procinfo to serialize this data and pass it to the
kernel. This is unnecessarily limiting (procinfo is read-only and
limited in size), and there may be other data we would like serialized
in the future. It would be unreasonable to keep expanding procinfo every
time we had a new data structure we wanted to serialize to the kernel.

This commit introduces a new struct serialized_data, which contains
nothing more than a size and an unbounded buffer. Serialization routines
can be written around this type to serialize their input and return a
newly allocated buffer with all of the serialized data contained in it.
All pointers in the data structure must be relative to the base of the
argument buffer itself (rather than absolute pointers).  I've written a
serializer for the argv and envp stuff to pack all of their data into a
single buffer. The plan is to use this new serialized representation to
replace the existing procinfo approach to passing this data into the
kernel (though that will come in a subsequent commit).  More serializers
can be written following this pattern as desired in the future.

I toyed around with the idea of not serializing the argv and envp data
at all, and just passing their pointers directly to the kernel. However,
this approach proved to get increasingly complicated as I started to
reason through what needed to be done to verify all of the user memory
while walking these data structures in the kernel. It's obviously doable
(linux does it this way, for example), but it is unnecessarily
complicated, and likely safer, to just pass the serialized data in.

By serializing the data, we can pass a single pointer and a
length to the kernel (similar to how we do for our path strings), and
the kernel can do a quick check to verify that all of the memory to be
accessed is mapped in and within bounds. I very much like this pattern,
moving forward, for all complicated data structures we may need to pass
to the kernel. We may not always be able to get away with it, but it
makes sense to use it when we can.

In terms of implementing this stuff, I put the actual code in glibc and
the header file in parlib. Ideally I would have put it all in parlib
(since it's not really a part of glibc), but I already know that
sys_exec will need access to these functions, and there may be others in
the future.  The header file belongs where it is though, as this really
is a parlib operation.

As part of this, I also wrote a simple test that demonstrates how the
serialization of argv and envp works. It is called serialize_test.

4 years agoRTLD_START passes correct args to _dl_init (XCC)
Kevin Klues [Thu, 9 Jul 2015 17:43:01 +0000 (10:43 -0700)]
RTLD_START passes correct args to _dl_init (XCC)

Previously, we used the default RTLD_START for x86_64, which relied on
argv and friends being passed in on the stack. In Akaros, we pass these
values in via procinfo, not on the stack.

RTLD_START is called after dl_open() is called, which uses our existing
implementation of DL_FIND_ARG_COMPONENTS in dl-sysdep.c to extract the
arguments properly from procinfo.  However, RTLD_START wasn't using
these extracted values when calling _dl_init(). It was attempting to
find these values on the stack (where they don't exist in Akaros!) and
then passing them to _dl_init(). In the new version, we now pass the
values extracted from our DL_FIND_ARG_COMPONENTS macro to
_dl_init() properly.

This problem was first noticed when I wanted to use the glibc-defined
variable 'program_invocation_name' in a test I was writing. Under the
hood, this variable takes the value of argv[0]. Statically linked
programs had this variable set properly.  Dynamically linked programs
didn't (because incorrect args were being passed to _dl_init()).

In fixing this stuff up, I noticed that we don't properly handle the
skipping of argments, as specified by _dl_skip_args when running
_dl_open().  The old implementation of RTLD_START took care to skip the
right number of arguments based on this variable and then patch up the
stack appropriately.  Since we get our arguments from procinfo, we can't
patch things up so easily (procinfo is read-only).  We'll either need to
come up with something cleverer, or somehow interpose on _start and push
our extracted arguments from procinfo onto the stack before calling
_start(). This may be the better approach overall since having the args
on the stack is technically part of the ELF ABI.

We also don't properly handle passing our _dl_fini() function as the 6th
argument to __libc_start_main(), or passing the start address of the
user-accessable stack as the 7th argument. We are passing a pointer to
_dl_fini() into _start properly (via %rdx as specified by the ELF ABI),
we just ignore it currently. We should revisit this in the (near)
future.

The new tests/progname.c should now work for both statically and
dynamically linked binaries. Previusly it only worked for statically
linked ones.

4 years agoAdd #include to remove warning for errstr()
Kevin Klues [Wed, 8 Jul 2015 19:22:09 +0000 (12:22 -0700)]
Add #include to remove warning for errstr()

4 years agoFix bug introduced when adding sem_timedwait
Kevin Klues [Tue, 7 Jul 2015 21:23:22 +0000 (14:23 -0700)]
Fix bug introduced when adding sem_timedwait

Previously, all we needed was the __sem, but now we have a wrapper
around it to support sem_timedwait()

4 years agoFixes arpread
Barret Rhoden [Mon, 6 Jul 2015 18:49:59 +0000 (14:49 -0400)]
Fixes arpread

We were converting from bytes to a string, and then trying to print that
string as a series of bytes (which is what %E does).  We only need to
convert the MAC addr once, in printk().

4 years agoUpdate Makelocal.template with 'akaros' (not ros)
Kevin Klues [Mon, 6 Jul 2015 16:13:40 +0000 (09:13 -0700)]
Update Makelocal.template with 'akaros' (not ros)

Also set default MAKE_JOBS equal to the number of cpus on the machine,
minus one

4 years agoComplete rewrite of Makefile
Kevin Klues [Thu, 2 Jul 2015 02:56:44 +0000 (19:56 -0700)]
Complete rewrite of Makefile

This was motivated by the desire to add new features to the makefil,
such as "make install-kernel-headers", etc. Before the rewrite, this was
hard to add in easily (if not impossible).  With the new way, you just
have to add a valid SUBCMD to the VALID_SUBCMDS variable and then add a
target for your new subcommand with a '-real' extension on it.  Use the
existing 'build' and 'uninstall' build rules as templates.  There is
also better support for adding in build time checks for things like
'gawk' being installed and 'X86_64_INSTDIR' being set.  You can use the
existing templates as an example if you want to add a new error check.

New semantics are as follows:

Usage: make <arch> [ <config> ] [ <subcmd> ]
    Valid archs are: 'x86_64', 'riscv'
    Valid configs are: 'cross', 'native'
    Valid subcommands are: 'build', 'uninstall'
    If no config is specified, the 'cross' config is assumed by default.
    If no subcommand is specified, the 'build' subcommand is assumed by default.

Additional pseudo targets exist for:
    make clean
        Cleanup the build environment
    make inst-clean
        Cleanup the build environment and uninstall all compilers for all archs.

4 years agoRemoves extra arch-> symlink (XCC)
Barret Rhoden [Fri, 26 Jun 2015 22:20:44 +0000 (15:20 -0700)]
Removes extra arch-> symlink (XCC)

This was the sysroot/usr/include/arch link, which used to point to x86
or riscv.  Those directories are now in sysroot/usr/include/parlib/.

You'll need to do a make inst-clean or manually remove the symlink,
though it is mostly harmless to leave the symlink around.

4 years agovmmcp: remove RDTSCP from the set of things that we support.
Ronald G. Minnich [Tue, 30 Jun 2015 19:19:11 +0000 (12:19 -0700)]
vmmcp: remove RDTSCP from the set of things that we support.

Yuck.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoDon't use an empty path for 9p mounts. Specify /.
Ronald G. Minnich [Tue, 30 Jun 2015 19:03:59 +0000 (12:03 -0700)]
Don't use an empty path for 9p mounts. Specify /.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoEnable "VMCALL console putc" via flags. (XCC)
Ronald G. Minnich [Tue, 23 Jun 2015 18:04:52 +0000 (11:04 -0700)]
Enable "VMCALL console putc" via flags. (XCC)

We extend the vmm struct with flags.

The only flag now is VMM_VMCALL_PRINTF. If this is set, then the vmcall handler
will print out the lowest byte of the first argument to the console.

Reinstall your kernel headers.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoMake vars overwritable / fix typo: S0 -> SO
Kevin Klues [Thu, 25 Jun 2015 22:08:08 +0000 (15:08 -0700)]
Make vars overwritable / fix typo: S0 -> SO

4 years agopre_2ls stuff is now unnecessary
Kevin Klues [Thu, 25 Jun 2015 22:54:05 +0000 (15:54 -0700)]
pre_2ls stuff is now unnecessary

4 years agoRedesign of our initialization path for libs (XCC)
Kevin Klues [Thu, 25 Jun 2015 22:32:04 +0000 (15:32 -0700)]
Redesign of our initialization path for libs (XCC)

Previously there was a big mismatch of how we performed various
initialization for our various libraries, such as vcores, uthreads,
pthreads, etc.

We now do initialization based on libc *constructors* functions as
defined with an __attribute__((constructor)) attribute.  Doing
initalizaton this way makes things more consistent, as well as ensures
that evertything we want to have initialized gets initialized early on in
the lifetime of an application, while at the same time allowing us to
easily add per-library initialization simply by linking in some extra
libraries.

We previously had a hodgepodge of workarounds to essentially try and
give us this functionality, none of which worked very well (mostly based
on overwriting weak symbols and/or calling certain functions (i.e.
vcore_event_init()) in places that made following the logic of
initialization confusing).  Now all startup initialization occurs via
*constructor* functions with the name '*_lib_init()' and depenencies are
preserved using 'init_once_racy()' calls as the very first call in each
of these functions, followed by calls to the specific *_lib_init()
functions they depend on. Following this discipline, all *_lib_init()
functions will be called *exactly* once, and all of them will be called
in the proper order (even if they get called multiple times, they will
only execute once due to the init_once_racy() call). The hacky call to
vcore_event_init() in _start is now completely eliminated with this
design.

As part of this redesign, a few modifications were also made to separate
out what it really means to "initailize" a uthread and "initialize" a
pthread vs. both intitializing these constructs as well as transitioning
into an MCP. Previously, initializing the uthread library implicitly
turned you into an MCP.  Now there is an explicit call for
uthread_mcp_init() (which is also wrapped by pthread_mcp_init()), who's
sole purpose is to transition a process into an MCP that is
uthread/pthread ready. It is this functionality that we *actually*
needed to ensure was executed whenever we first call pthread_create()
and friends, not the simple initialization of thread0 to become a
uthread/pthread (that now happens inside our new constructor
functions at startup time).  Moreover, the old uthread_lib_init() is now
called uthread_2ls_init() in order to accommodate the new naming
convention, and it does essentially the same thing it did before (minus
the automatic transition into an MCP).

Because of this change in semantics, all tests that were previously
calling pthread_lib_init() explicitly (rather than relying on
pthread_create() to call it implicitly) must now call pthread_mcs_init()
instead.  This is actually more intuitive, given what its purpose is.

4 years agoRename vcore_init() -> vcore_lib_init()
Kevin Klues [Tue, 23 Jun 2015 20:09:09 +0000 (13:09 -0700)]
Rename vcore_init() -> vcore_lib_init()

This is to standardize on the naming for functions in the library that
should only be called once and perform initialization.

4 years agoGet rid of weak symbol overriding for sched_ops
Kevin Klues [Thu, 25 Jun 2015 22:26:50 +0000 (15:26 -0700)]
Get rid of weak symbol overriding for sched_ops

We now dynamically override these variables inside of our 2LS lib_init
function.  This applies similarly to our signal_ops struct as well.

4 years agoUpdates lockprov.sh
Barret Rhoden [Tue, 23 Jun 2015 18:04:33 +0000 (11:04 -0700)]
Updates lockprov.sh

Helps catch the deadlock with MCS-PDR locks.

Once the output stops scrolling, CTRL-G to get in the monitor, ps, then
kill the lockprov script (called ash, but it's PID is just a couple less
than lock_test).  Killing it just cuts down on other system activity and
gives you your shell back.

4 years agoFixes SYS_vc_entry numbering (XCC)
Barret Rhoden [Tue, 23 Jun 2015 17:45:23 +0000 (10:45 -0700)]
Fixes SYS_vc_entry numbering (XCC)

SYS_vc_entry was using the same number as SYS_abort_sysc.  I think I was
trying to keep vc_entry with similar calls, but didn't want to mess with
the numbers.  Clearly that was wrong, since I later used 31 again.

Incidentally, the last initializer wins for gcc, though a warning might
have been nice (not sure if there is a legitimate usage of this).
https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

Reinstall the kernel header and rebuild userspace.  No need to rebuild the
toolchain.

4 years agovmmcp: coreboot_tables: Add a reserved region from 0 -> base of memory.
Ronald G. Minnich [Tue, 23 Jun 2015 16:31:33 +0000 (09:31 -0700)]
vmmcp: coreboot_tables: Add a reserved region from 0 -> base of memory.

Some kernels want to see a definition of the hole below real memory.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoAdds hexdump to a parlib header
Barret Rhoden [Mon, 22 Jun 2015 23:31:00 +0000 (16:31 -0700)]
Adds hexdump to a parlib header

For debugging.

4 years agovmmcp: Rework coreboot tables support
Ronald G. Minnich [Thu, 18 Jun 2015 15:00:38 +0000 (08:00 -0700)]
vmmcp: Rework coreboot tables support

Adds the user header and makes coreboot_table compile.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Git-fu'd-by: brho
Commended-by: brho and Ronald G. Minnich <rminnich@gmail.com>
4 years agoImport coreboot table support code.
Ronald G. Minnich [Thu, 18 Jun 2015 15:00:38 +0000 (08:00 -0700)]
Import coreboot table support code.

This won't compile.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agovmmcp: Handle cpuid.
Ronald G. Minnich [Thu, 18 Jun 2015 14:14:46 +0000 (07:14 -0700)]
vmmcp: Handle cpuid.

And some cleanup.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agovmmcp: this should be the complete list of registers we need to autoload
Ronald G. Minnich [Tue, 16 Jun 2015 05:23:03 +0000 (22:23 -0700)]
vmmcp: this should be the complete list of registers we need to autoload

If we set FS_BASE and GS_BASE on autoload, vmmcpkernel causes
a vmware machine check. Why?

For LSTAR:
You have to disable intercept but also for this one do autoload.

If you don't disable intercept then the guest can not read or set it.
If you don't set autoload and the guest sets it, then this non-virtualized
register will probably kill your kernel.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoVMM: repurpose vmcall for a temporary console
Ronald G. Minnich [Sat, 13 Jun 2015 04:26:00 +0000 (21:26 -0700)]
VMM: repurpose vmcall for a temporary console

We can now get part way through Plan 9

The console thing is incredibly wonderfully convenient.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoVMM: Adds Ron's test programs
Barret Rhoden [Mon, 15 Jun 2015 19:07:59 +0000 (15:07 -0400)]
VMM: Adds Ron's test programs

This collection is from a bunch of partial commits.

4 years agoAdds a tests/vmm subdirectory
Barret Rhoden [Mon, 15 Jun 2015 19:00:29 +0000 (15:00 -0400)]
Adds a tests/vmm subdirectory

We're going to have a bunch of these; makes sense to compartmentalize them.

Btw, don't use the same name for a program in the subdirectory as in the main
tests/ directory.  They'll collide at fill-kfs time.

4 years agoVMM: Remove #ifdef x86_64 from vmx.c
Ronald G. Minnich [Sat, 13 Jun 2015 15:40:59 +0000 (08:40 -0700)]
VMM: Remove #ifdef x86_64 from vmx.c

Not building it for 32 bit.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Git-fu'd-by: brho

4 years agox86: Show epte value when printing the kpte.
Ronald G. Minnich [Fri, 12 Jun 2015 21:35:10 +0000 (14:35 -0700)]
x86: Show epte value when printing the kpte.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Git-fu'd-by: brho

4 years agoMakes virtio_ring.h a kernel header (XCC)
Barret Rhoden [Mon, 15 Jun 2015 16:19:47 +0000 (12:19 -0400)]
Makes virtio_ring.h a kernel header (XCC)

virtio_ring.h is about communication across the user-kernel boundary.  Or
rather a kernel/VMM boundary, or any other sort of boundary with a
shared-memory interface.

In contrast, virtio.h is more about the implementation of functions for use
within the kernel/user/vm, so for now we'll keep those separate.

Reinstall your headers or rebuild the toolchain.

4 years agoAdd basic vmm library
Ronald G. Minnich [Wed, 8 Apr 2015 22:14:26 +0000 (15:14 -0700)]
Add basic vmm library

Questions: are the .h files in the right place? do they need to be in ros? I'm
once again confused by the akaros include scheme.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Git-fu'd-by: brho

4 years agoRemoves unnecessary prot check
Barret Rhoden [Mon, 15 Jun 2015 15:52:45 +0000 (11:52 -0400)]
Removes unnecessary prot check

We check the prot against the VMR's prot later, and will return with -EPERM if
there was a problem.  This popped up as an issue since the EPT can have
multiple fault types at the same time within the prot field.

Of course, we may still have issues with EPT having prot fields that don't jive
with the VMR, so be on the lookout for EPERMs.

4 years agoAdds Ron's VMWARE Fusion on OSX pxeboot script
Ronald G. Minnich [Fri, 24 Apr 2015 15:22:06 +0000 (08:22 -0700)]
Adds Ron's VMWARE Fusion on OSX pxeboot script

This does the full build, drops the resulting akaros binary
somewhere sensible, and kicks the isc dhcp server.

You can then restart your fusion-based akaros VM and it will
"net" boot.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoTurn down the debug prints, add a couple extra
Ronald G. Minnich [Thu, 16 Apr 2015 23:35:28 +0000 (16:35 -0700)]
Turn down the debug prints, add a couple extra

Things are working well enough that we don't need all this
gabby behavior. Turn it down.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Git-fu'd-by: brho

4 years agoVMM: vmresume works! (handle IRQ)
Ronald G. Minnich [Thu, 16 Apr 2015 21:22:24 +0000 (14:22 -0700)]
VMM: vmresume works! (handle IRQ)

Things are way smoother; we exit the vm loop when we get an interrupt.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoVMM: Rip out testing code.
Ronald G. Minnich [Wed, 15 Apr 2015 17:32:09 +0000 (10:32 -0700)]
VMM: Rip out testing code.

It's mostly no longer useful and probably no longer right.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoRemoves user symlinks from the sysroot (XCC)
Barret Rhoden [Thu, 18 Jun 2015 14:49:58 +0000 (10:49 -0400)]
Removes user symlinks from the sysroot (XCC)

And installs user headers into sysroot/usr/include/libname/.  Now all
programs must include user libraries with #include <libname/header.h>.
I fixed up all of our tests, but external programs will need to be
changed manually.

To be sure these changes kicked in, remove your existing toolchain
installation and rebuild.  Then rebuild all other programs.

$ cd tools/compilers/gcc-glibc/
$ make inst-clean
$ make x86_64

4 years agoChanges user includes to <library/header.h> (XCC)
Barret Rhoden [Thu, 18 Jun 2015 14:18:04 +0000 (10:18 -0400)]
Changes user includes to <library/header.h> (XCC)

This has been an option for a long time, due to the symlinks dropped in
the sysroot/usr/include during the user libs FINAL_INSTALL, but will be
mandatory soon.

Rebuild your toolchain.

4 years agoAdds include symlinks for user libraries
Barret Rhoden [Thu, 18 Jun 2015 14:06:07 +0000 (10:06 -0400)]
Adds include symlinks for user libraries

With these symlinks, code from within the library can find its own
headers with something like #include <parlib/parlib.h>, just like other
code (e.g. tests/whatever.c).  I also removed the library directory (.)
from the -I search path.

I didn't do this for pthreads, since pthread code is only included with
 #include <whatever.h>, and not #include <pthread/whatever.h>.

4 years agoConsolidates user library Makefiles
Barret Rhoden [Thu, 18 Jun 2015 15:46:31 +0000 (11:46 -0400)]
Consolidates user library Makefiles

Most user libraries do the same thing; there's no need to replicate the
makefile contents, and it's a pain.

One slight change is that the libraries other than parlib didn't have
the DEPLIBAS on the ARCH/%.o target, which was probably a bug.

4 years agoMoves profalarm.h into pthread.h
Barret Rhoden [Thu, 18 Jun 2015 13:58:58 +0000 (09:58 -0400)]
Moves profalarm.h into pthread.h

Due to an upcoming change, we don't want any non-glibc pthread header files,
since they will sit directly in sysroot/usr/include.  That being said, futex.h
is probably okay.

Also, fixes up a discrepancy between the declaration and definition of
enable_profalarm().  Not sure why that compiled before...

4 years agoCleans up and renames ndblib
Barret Rhoden [Wed, 17 Jun 2015 22:41:55 +0000 (18:41 -0400)]
Cleans up and renames ndblib

Ndblib was named ndb when it was installed; this changes it to ndblib.

We could either rename it completely to ndb (directory and everything)
and do the same for iplib, or just keep it called ndblib.  Given that
the libs are dropped into the sysroot directly, keeping them as iplib
and ndblib decreases the chance for collisions.

Moves ndbhf.h to an include/.  Any user .h file other than the pthread
headers needs to be in an include directory.

4 years agoRemoves unneeded userland headers
Barret Rhoden [Wed, 17 Jun 2015 21:26:11 +0000 (17:26 -0400)]
Removes unneeded userland headers

parlib/pthread.h was around in case you build parlib but not pthreads.
No one does this anymore.

The tests headers were the most useless of a large batch of cruft.

4 years agoToolchain target: make inst-clean
Barret Rhoden [Thu, 18 Jun 2015 15:05:24 +0000 (11:05 -0400)]
Toolchain target: make inst-clean

Convenience target, it will clean and remove the contents of all
installed toolchains (riscv, x86_64, etc).

If you want finer-grained uninstallation, there are still the specific
uninstall targets, e.g. make x86_64-uninstall.

4 years agoImplements getaddrinfo() (XCC)
Barret Rhoden [Thu, 11 Jun 2015 22:18:10 +0000 (18:18 -0400)]
Implements getaddrinfo() (XCC)

Rough version of getaddrinfo.  It only works for IPv4 and has limited support
for various socktypes and protocols.  It calls out to cs for name resolution,
but cs currently deadlocks at runtime.

Rebuild glibc.

4 years agoAdd level of indirection for signal funcs in 2LS
Kevin Klues [Sat, 6 Jun 2015 00:31:50 +0000 (17:31 -0700)]
Add level of indirection for signal funcs in 2LS

Some signal functions (like sigprocmask()) are 2LS specific and need to
be implemented as such. We use a level of indirection similar to the
sched_ops for this.

4 years agoUse local "*.h" instead of installed <*.h>
Kevin Klues [Sat, 6 Jun 2015 00:30:22 +0000 (17:30 -0700)]
Use local "*.h" instead of installed <*.h>

This is necessary in case the API or something has changed between the
installed version and the one currenlty being built.

4 years agoDrop _NSIG to 42 instead of 65 (XCC)
Kevin Klues [Fri, 5 Jun 2015 23:14:54 +0000 (16:14 -0700)]
Drop _NSIG to 42 instead of 65 (XCC)

_NSIG represents the biggest signal number + 1 (including real-time signals).
We choose 42 in homage to h2g2, but also to show that it's not a magic number,
like 32 or 64.  It just happens to be the number of rt signals that we may
(probably won't support in the future).  At any rate, this number must ALWAYS
be <= 64 because we are using a long to represent a sigset.  In Akaros we will
likely impelment all necessary real-time stuff (if we need it) using events
directly, so this point is moot.  Leaving it at 65 was problematic though
because you can't represent all signals (based 1) in a single long, adding to
weird bugs that we would like to avoid in the future.

This helped to fix a bug whee I was previously trying to optimize my
signhandler array to only create (_NSIG - 1) entries because I knew
there were only 64 signals (0 is invalid), but I messed up my mappings
when reuqired to subtract 1 when indexing into this array
to get my signal.  Better to just create one extra entry and call it a
day. However, we need to make sure that all signals can be represented
in our sigmasks (Go cares about this for example, as it installs
handlers for all of its signals up to _NSIG).  If something is off here,
we are (and have been) screwed.

4 years agoReentrant versions of get{prt,srv}name (XCC)
Barret Rhoden [Fri, 5 Jun 2015 20:10:04 +0000 (16:10 -0400)]
Reentrant versions of get{prt,srv}name (XCC)

Similar to the gethostbyname* versions.  They each have slight differences.
The get-service-by-protocol uses srvbynm under the hood, since it's all the
same to CS.

As with gethostbyname*, these haven't been tested and may have the same old
bugs from the original plan 9 shims.

Rebuild glibc.

4 years agoReentrant version of gethostbyname (XCC)
Barret Rhoden [Fri, 5 Jun 2015 19:11:06 +0000 (15:11 -0400)]
Reentrant version of gethostbyname (XCC)

Ports the plan 9 version of gethostbyname to gethostbyname2_r, and implements
the others with it.  Hard to know if this actually works, since we don't use CS
much.  So it may be just as buggy as it was before, but now is reentrant, and
possibly with new bugs (I had several during this commit).

Also, the old version didn't close the fd in all error cases, so at least
that's fixed now.

Rebuild glibc.

4 years agoEnable fortran support in gcc
Kevin Klues [Thu, 11 Jun 2015 23:22:50 +0000 (16:22 -0700)]
Enable fortran support in gcc

Also, we need to enable c++ and gfortran at stage2 of gcc build, not
stage3, otherwise our specs file is messed up and we can't invoke
g++ or gfortran from a straight gcc call.

4 years agoUse the e1000 in kvm since it can use big addresses
Ronald G. Minnich [Thu, 11 Jun 2015 20:26:06 +0000 (13:26 -0700)]
Use the e1000 in kvm since it can use big addresses

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
4 years agoRemoves libbsd (XCC)
Barret Rhoden [Thu, 4 Jun 2015 20:14:28 +0000 (16:14 -0400)]
Removes libbsd (XCC)

All the functionality should be in glibc or is not needed.

To be safe, remove your toolchain installation and rebuild.  Just removing
libbsd.a is probably enough.

4 years agoPushes the Plan 9 BSD shims into glibc (XCC)
Barret Rhoden [Thu, 4 Jun 2015 19:55:17 +0000 (15:55 -0400)]
Pushes the Plan 9 BSD shims into glibc (XCC)

Glibc had stubs that we were overriding in libbsd.  Those shims ought to be in
glibc, since that's Akaros's way of implementing various socket calls.  This is
also somewhat necessary for some -Werror situations where glibc links with its
versions (which were throwing stub_warnings).

Most functions from libbsd are now in glibc.  nptohl() was removed; no one was
using it.  {get,set}sockopt() were stubs in libbsd that did nothing.  I went
with modified glibc stubs for those.  They won't throw compiler warnings, but
they will fail at runtime.  And with a more appropriate errno.  We can add in
various socket options if they are important.

The bulk of the functions were brought over "as is", with the existing races and
non-reentrancy.  A few of them needed work, since the SOCKADDR_ARG has a
different type within glibc (transparent union).  I did pass the files through
lindent, since they have a fresh git history and needed some formatting.

Rebuild glibc.

4 years agoAdds sunrpc (XCC)
Barret Rhoden [Thu, 4 Jun 2015 04:46:31 +0000 (00:46 -0400)]
Adds sunrpc (XCC)

Some applications (e.g. lmbench) seem to want sunrpc.  It wasn't too hard to
add it back in.  Most of sunrpc should work (we'll see!) but the authentication
stuff relies on NSS.  I've stubbed out a couple of those functions.

Note that netname.c needed to be changed in the sunrpc directory, and a sysdep
was insufficient.  Check out my notes in Documentation/glibc.txt for more info.

Also, we needed to --enable-obsolete-rpc to get any rpc/ headers, other than
netdb.h.  That's a recent change (2012).

Rebuild glibc.

4 years agoAdds a backtrace helper for user backtraces
Barret Rhoden [Tue, 2 Jun 2015 18:26:25 +0000 (14:26 -0400)]
Adds a backtrace helper for user backtraces

You need to echo the Akaros backtrace (e.g. #1 Addr f00 is in BAR) into the
script.  You'll also need to customize the script for your system.  I recommend
copying it out of scripts/ and onto your own system somewhere.

You can also source the script, then ctrl-d it, and manually invoke
print_glb_func.

$ print_glb_func kern/kfs/bin/hello 0xADDR

Make sure the ADDR is in hex, with a leading 0x.  If all goes well, it'll print
out the function containing ADDR.

4 years agoAllows calls to pthread_sigmask before init
Barret Rhoden [Fri, 29 May 2015 16:20:51 +0000 (12:20 -0400)]
Allows calls to pthread_sigmask before init

Some libraries that ld loads make pthread calls in their initialization.  This
patch tracks the changes made to the sigmask, and applies it when the 2LS is up
and running.

One issue is that the sigmask is for the pthread only, and not the entire
process.  Hopefully that's what these libraries wanted.  Maybe it isn't.

Another approach would be to find a safe spot in ld and run vcore_event_init()
from there, such that we get the slim 2LS init done very early.  Then we add a
2LS op for the slim-init (e.g. pth_slim_init), which does the basics to track
the pthread as thread0, but doesn't turn us into an MCP.  This is doable in
part since the specific 2LS is determined statically, for instance when you
link against -lpthread.

If we do the latter approach, we will still need to call out from the
application's _start for staticly linked applications.