Change hyperlinks to point to .md files

Allows mkdocs to discover broken links when the pointed document has
moved.

doc/dev/channels.md

@@ -65,5 +65,5 @@ to write the duplicated value with no error.
 A unique function can be set to each channel which will be called once a channel
 becomes dirty with `chan_set_dirty_cb()`. This callback will be called before
 `chan_set()`, `chan_push()` or `chan_pop()` returns. The [patch
-bay](../patchbay) uses this callback to detect when a channel is modified an run
+bay](patchbay.md) uses this callback to detect when a channel is modified an run
 other callbacks.

doc/dev/model.md

@@ -22,7 +22,7 @@ If the model is not enabled, no other function will be called.
 
 The create function is called for each enabled model to allow them to allocate
 all the required structures to perform the emulation using the
-[extend](../extend) mechanism. All the required channels must be created and
+[extend](extend.md) mechanism. All the required channels must be created and
 registered in the patch bay in this function, so other models can found them in
 the next stage.
 

doc/dev/mux.md

@@ -1,6 +1,6 @@
 # Mux
 
-The emulator provides a mechanism to interconnect [channels](../channels) in a
+The emulator provides a mechanism to interconnect [channels](channels.md) in a
 similar way as an [analog
 multiplexer](https://en.wikipedia.org/wiki/Multiplexer) by using the `mux`
 module.
@@ -19,7 +19,7 @@ selected. This allows a multiplexer to act as a filter too.
 
 The typical use of multiplexers is to implement the tracking modes of channels.
 As an example, the following diagram shows two multiplexers used to implement
-the subsystem view of [Nanos6](../nanos6):
+the subsystem view of [Nanos6](../user/emulation/nanos6.md):
 
 ![Mux example](fig/mux.svg)
 
@@ -51,5 +51,5 @@ Multiplexers allow models to interact with each other in a controlled way. In
 the example, the blue channel (*nanos6.thread0.subsystem*) is directly modified by
 the Nanos6 model when a new event is received. While the red channels are
 controlled by the ovni model.  The rest of the channels are automatically updated
-in the propagation phase of the [bay](../patchbay) allowing the ovni model to
+in the propagation phase of the [bay](patchbay.md) allowing the ovni model to
 modify the Nanos6 Paraver view of the subsystems.

doc/dev/paraver.md

@@ -16,7 +16,7 @@ A channel can be connected to each row in a trace with `prv_register()`, so the
 new values of the channel get written in the trace. Only null and int64 data
 values are supported for now.
 
-The emission phase is controlled by the [patch bay](../patchbay) and runs all
+The emission phase is controlled by the [patch bay](patchbay.md) and runs all
 the emit callbacks at once for all dirty channels.
 
 ## Duplicate values

doc/dev/patchbay.md

@@ -1,6 +1,6 @@
 # Patch bay
 
-The patch bay (or simply bay) allows [channels](../channels/) to be registered
+The patch bay (or simply bay) allows [channels](channels.md) to be registered
 with their name so they are visible to all parts of the emulator and provides a
 way to run callbacks when the channels update their values.
 

doc/index.md

@@ -13,8 +13,10 @@ The ovni project implements a fast instrumentation library that records
 small events (starting at 12 bytes) during the execution of programs to
 later investigate how the execution happened.
 
-The instrumentation process is split in two stages: [runtime](runtime)
-tracing and [emulation](emulation/).
+<!-- FIXME: Add a index for runtime -->
+The instrumentation process is split in two stages:
+[runtime](user/runtime/tracing.md)
+tracing and [emulation](user/emulation/index.md).
 
 During runtime, very short binary events are stored on disk which
 describe what is happening. Once the execution finishes, the events are

doc/user/emulation/index.md

@@ -47,7 +47,7 @@ the following elements:
 
 - A single byte model identification (for example `O`).
 - A set of runtime events with that model identification (see the [list
-  of events](events)).
+  of events](events.md)).
 - Rules that determine which sequences of events are valid.
 - The emulation hooks that process each event and modify the state of
   the emulator.

doc/user/emulation/nosv.md

@@ -60,7 +60,7 @@ For more details, see [this MR][1].
 
 The subsystem view provides a simplified view on what is the nOS-V
 runtime doing over time. The view follows the same rules described in
-the [subsystem view of Nanos6](../nanos6/#subsystem_view).
+the [subsystem view of Nanos6](nanos6.md/#subsystem_view).
 
 
 ## Idle view

doc/user/emulation/ovni.md

@@ -60,4 +60,4 @@ will set all the channels to an error state.
 The emulator automatically switches the channels from one thread to
 another when a thread is switched from the CPU. So the different models
 don't need to worry about thread transitions. See the
-[channels](../channels) section for more information.
+[channels](../../dev/channels.md) section for more information.

doc/user/runtime/tracing.md

@@ -24,7 +24,7 @@ trace is correct.
 
 You can use `ovni_ev_emit()` to record a new event. If you need more
 than 16 bytes of payload, use `ovni_ev_jumbo_emit()`. See the [trace
-specification](../trace_spec) for more details.
+specification](trace_spec.md) for more details.
 
 Compile and link with libovni. When you run your program, a new
 directory ovni will be created in the current directory `$PWD/ovni`