Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
K
kernel
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
jD91mZM2
kernel
Commits
fb20ed54
Commit
fb20ed54
authored
8 years ago
by
Jeremy Soller
Browse files
Options
Downloads
Patches
Plain Diff
Add contributing and readme
parent
dc53add6
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+69
-0
69 additions, 0 deletions
README.md
with
69 additions
and
0 deletions
README.md
0 → 100644
+
69
−
0
View file @
fb20ed54
# kernel
A collaborative effort to rewrite the kernel with focus on correctness and code
quality.
## Why?
The kernel code was getting increasingly messy to the point where only the
original writer would be able to find and fix bugs. Fortunately, the kernel of
Redox is relatively small and such a project is estimated to take only a few
months.
## What?
The aims of the new kernel should be clear in their order:
1.
**Correctness**
: Above anything else, the kernel should be correct. No hacks,
despite how the tiny cool shortcuts might seem, it gives severe backslash later
on. Keep it correct and well-written.
2.
**Readability and documentation**
: The code quality should be high, with that
follows a detailed documentation, including both API docs (on every item!) and
careful comments for anything non-trivial.
3.
**Performance**
: If you can, go for it.
## Guidelines
### A rotten house is built on a rotten fundament.
Don't fool yourself. You are likely not getting back to the ugly code. Write it
the right way
**first time**
, and make sure you only move on when it's
**done right**
.
### Comments
Do not hesitate to put comments all over the place.
### Documentation
Every public item should contain API documentation.
### Debug assertions
Abusing debug assertions is a wonderful way to catch bugs, and it is very much
encouraged.
### Statical checking
Rust provides a lot of type-system features which can be used to create
wonderful safe abstractions, and you should use them whenever you get the chance.
Unsafety should be avoided, and if it is triggered only under some addition
**insert an assertion**
. Despite this being a kernel, we prefer kernel panics
over security vulnerabilities.
If the condition is (or should be) unreachable, but if not upheld, leading to
UB, put an assertion in the start of the function.
### Be gentle
Don't just write as much code as you can as quick as possible. Take your time
and be careful.
### Commits
Use descriptive commits. One way to force yourself to do that is to not pass the
`-m`
flag, which will make your editor pop up, so that you can conviniently
write long commit messages.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment