diff --git a/Makefile b/Makefile index 31e9fd6..892a464 100644 --- a/Makefile +++ b/Makefile @@ -236,6 +236,9 @@ docs/%.html: % $(Q)mandoc -Tlint $< || exit 1 $(Q)mandoc -Thtml -I os=$(shell uname -s) \ -Otoc,style=mandoc.css,man=%N.%S.html $< > $@ + $(Q)sed -i 's/fork\.2\.html/https:\/\/linux.die.net\/man\/2\/fork/g' $@ + $(Q)sed -i 's/exec\.3\.html/https:\/\/linux.die.net\/man\/3\/exec/g' $@ + $(Q)sed -i 's/exit\.3\.html/https:\/\/linux.die.net\/man\/3\/exit/g' $@ docs: $(DOCS_HTML) README.md docs/index.html diff --git a/docs/index.html b/docs/index.html index 96fc51d..9753dc3 100644 --- a/docs/index.html +++ b/docs/index.html @@ -40,15 +40,15 @@

fork(2), - exec(3), - exit(3) and others.

+ system-wide events like fork(2), + exec(3), + exit(3) and others.

quark not only provides an API for listening to events, but also handles ordering, buffering and aggregation of said events. In its most basic form, a short lived process consisting of - fork(2) + - exec(3) + - exit(3) will be aggregated into one + fork(2) + + exec(3) + + exit(3) will be aggregated into one quark_event. An internal process cache is also kept that can be looked up via quark_process_lookup(3).

@@ -69,12 +69,12 @@

<
quark buffers and aggregates related events that happened close enough. The common case is generating a single event for - the triple: fork(2), - exec(3), - exit(3). There are rules on what can + the triple: fork(2), + exec(3), + exit(3). There are rules on what can be aggregated, and only events of the same pid are aggregated. For example: quark won't aggregate two - exec(3) events, otherwise we would + exec(3) events, otherwise we would lose the effects of the first one. These rules will be exposed and configurable in the future.
diff --git a/docs/mandoc.css b/docs/mandoc.css index a3cab23..feda8ff 100644 --- a/docs/mandoc.css +++ b/docs/mandoc.css @@ -358,6 +358,11 @@ h2.Sh, h3.Ss { margin-left: 0em; } text-indent: -2em; } } +html { +:link { color: #24bbb1; } +:visited { color: #24bbb1; } +} + /* Overrides for a dark color scheme for accessibility. */ /* @media (prefers-color-scheme: dark) { @@ -368,7 +373,3 @@ html { --bg: #1E1F21; } */ -html { -:link { color: #24bbb1; } -:visited { color: #e55098; } -} diff --git a/docs/quark.7.html b/docs/quark.7.html index 96fc51d..9753dc3 100644 --- a/docs/quark.7.html +++ b/docs/quark.7.html @@ -40,15 +40,15 @@

fork(2), - exec(3), - exit(3) and others.

+ system-wide events like fork(2), + exec(3), + exit(3) and others.

quark not only provides an API for listening to events, but also handles ordering, buffering and aggregation of said events. In its most basic form, a short lived process consisting of - fork(2) + - exec(3) + - exit(3) will be aggregated into one + fork(2) + + exec(3) + + exit(3) will be aggregated into one quark_event. An internal process cache is also kept that can be looked up via quark_process_lookup(3).

@@ -69,12 +69,12 @@

<
quark buffers and aggregates related events that happened close enough. The common case is generating a single event for - the triple: fork(2), - exec(3), - exit(3). There are rules on what can + the triple: fork(2), + exec(3), + exit(3). There are rules on what can be aggregated, and only events of the same pid are aggregated. For example: quark won't aggregate two - exec(3) events, otherwise we would + exec(3) events, otherwise we would lose the effects of the first one. These rules will be exposed and configurable in the future.