~vdupras/duskos

duskos/fs/doc/design/limits.txt -rw-r--r-- 4.9 KiB
c515797bVirgil Dupras comp/c/vm/i386: fix integer promotion bug in logical ops 3 hours ago
                                                                                
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
# Computing within limits

Dusk OS' authors believe that an important factor in software complexification
is the inability to accept limits. We are so used to some of modern conveniences
that we became blind to the complexities that they inherently bring and we
forget to consider the weight of that complexity in the tradeoff balance.

Dusk OS prioritizes simplicity in an aggressive way at the cost of many modern
conveniences.

## Concurrency

Concurrency has been with us for so long that, as software developers, we've
internalized its primary constraint: global variables and states should be
avoided.

To some of us, avoiding these became a second nature, so much that we don't even
see the complexity associated with these habits anymore.

However, it's surprising how much simpler problems become once you can assume
linear computation and thus have global variables and states. When there's less
indirection, the mechanisms to manage them can be simpler, which itself weights
less and needs less indirection to manage, and so on.

The gain in simplicity is too good to pass, which prompts the question: what do
we need concurrency for?

In a modern UNIX system, we sure use many processes at once and switch between
them. But do we really need to? When your text editor is active, your shell
doesn't need to run. The only reason we keep those two process around is because
the memory associated with one would be lost if you killed it. But that's UNIX'
own fault for managing memory in the way it does. Because Dusk's memory is
globally shared, it doesn't need this crutch.

Sometimes, we have background processes crunching numbers and we'd like to
interact with the computer from some other task that is not CPU intensive. It
doesn't happen as often as we think (or at least, not for real reasons; that is,
reasons that aren't caused by the mis-designs of our OS or workflow), but it
does happen. Those cases can easily be solved by cooperative multi-tasking,
that is, a simple system-wide idle loop where pieces of code can be hooked to
perform a background process. Sure, this might lead to annoying pauses in
interactivity, but really, these situations don't happen as often as we think
they do.

Another usage of concurrency is to maximally use hardware with multiple CPUs
or CPU cores. Because modern hardware is massively overpowered for Dusk's
design, we choose to ignore those spurious CPUs. One could imagine using them
in Dusk for some specific number crunching purposes, but they will have to
build isolation mechanisms for those computations themselves. This use case is
not important enough to sacrifice simplicity.

## Memory

Dusk's memory is globally shared and there is no virtual memory mechanism. When
you access a memory address in the system, it's a direct address. As an OS that
wants to be maximally useful to the bare metal hacker, we want to have as few
layers of indirection as possible leading to that hardware. Also, simplicity.

In programs, memory is generally statically allocated in sizes sufficient to
handle reasonable workloads of that program. The statically allocated sizes
are configurable system-wide when it makes sense and the effect of changing
those sizes is documented as well as possible.

TODO: include arena allocators in this text

Semi-temporary data is managed through the use of statically allocated "rolling"
buffers that we call "scratchpads" (lib/scratch). They're used like a dynamic
allocation except you don't ever free them. Instead, you hold them for as short
a time as possible, before the scratch pad has the time to overwrite your data.

As with other static buffers, scratchpads have a size that is designed to handle
reasonable workloads before overwriting data that's in use and when that makes
sense, this size is configurable system-wide to allow an operator with irregular
workloads (or exceptional memory constraints) to adjust it.

This means that applications will need to be accompanied by resource usage
analysis. It's a bit less convenient than a simple malloc(), but in a macro
perspective, this helps simplicity a lot. It's surprising how the need to call
free() on dynamically allocated memory shapes code in ways that make it a
lot more complex. When you remove that thorn, things become much simpler.

4GB ought to be enough for anybody, which is why the OS doesn't support any
64-bit type. Some specialized applications might need 64-bit numbers, but
they'll have to make their own abstractions.

## Text interface

While Dusk OS will be able to display graphics (for example, to render a PDF on
screen), it won't have a GUI. The way to interact with the system is through
text.

## Assume grid display

UNIX consoles, being based around a serial interface, are more complex than they
should be (curses etc.). Dusk OS is able to be accessed serially, but with
greatly reduced powers. The "full featured" console as well as most interesting
applications will assume a grid display.