Last active
August 29, 2015 14:06
-
-
Save jaredallard/0fa61943db26ba160dd3 to your computer and use it in GitHub Desktop.
All design specifications related to ccLinux and/or about it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ccLinux code standards. | |
APIs: Must be object oriented. | |
Tabs/Spaces: Tab | |
All code __must__ be formatted correctly when contributing to ccLinux, otherwise your pull request /will/ be denied. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
What we don't need to provide: | |
- Device specfic instructions | |
- ASM (ASM is the root of all evil) | |
- PCI, and other hardware related APIs/Interface. | |
What we /do/ need to provide: | |
# Process management (PID, and more) | |
- Internal Links (hard & soft) | |
# Periphal Drivers w/ IDs and other unique methods | |
X Complete Source Code. | |
- Filesystem API (ie adding custom filesystems.) (One file, or what?) | |
- i/o support. | |
- Complete hookin ability, for DEs or ontop-of OS boots. | |
X Virtual Memory (like page files) (acting as physical memory) | |
- Network API | |
X Built in JSON support. | |
- STDIN STDERR AND STDOUT streams | |
- Users | |
- External API useage | |
What needs to be done aside from needed to provide. | |
- Find a way to UNIQUELY identifiy peripheral devices |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Executable Lua Format, or ELF (or alternatively ELuF) Specifications. | |
File extensions: .elf, .celf (exclusively for compiled Lua) or .eluf. | |
Format: | |
|id|fl|hs|code| | |
id: Ascii "ELF", identifying an el(u)f file. | |
fl: Flags for the executable | |
hs: Hash of code (for corruption detection), hash would be in SHA-256 | |
code: The code/bytecode itself | |
Flags (each one character long): | |
c - Tells parser that this EL(u)F file has compiled code | |
n - Tells parser that there are no flags | |
That's about it (for now). | |
Fields are terminated by a "#:t", except for the code field. | |
The code field begins directly after the point where the hs field is terminated. | |
Suggestions: | |
1. Implement this, or support it's implementation | |
2. Have kernel source in github, but have it be compiled to celf (EL(u)F with compiled lua code) | |
3. Bootloader I just pushed would, in this case, be extended as an ELF parser and would load and run the kernel image. This would greatly increase the load performance among other things, such as it being really cool. | |
4. GNU coreutils ports should be compiled to celf for above reasons | |
EDITED TO GIVE EXAMPLE AND BREAKDOWN OF FORMAT: | |
Example of this format: (not celf) | |
hello.elf [ | |
ELF#:tn#:ta5a797fdacc9298ce69f407265bc5afb#:tprint("Hi!") | |
] | |
Above program prints Hi! and exits. The only difference here is because I'm lazy I used MD5 in the terminal rather than looking up a SHA256 hasher online, but you get the point. | |
Breakdown: | |
hello.elf [ | |
ELF|n|ta5a797fdacc9298ce69f407265bc5afb|print("Hi!") | |
] | |
id |fl| hs | code | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can you do PRs on gists? If not I'll move it to a git repo.