Show HN: Minimal freestanding C runtime for bare-metal/embedded PC projects | Hacker News Reader

Show HN: Minimal freestanding C runtime for bare-metal/embedded PC projects

github.com

97 pointsmarssaxman14 comments

It's the basis for another project of his called 'fleet': https://github.com/marssaxman/fleet

The idea for fleet (and thus for startc) is to work inside a hypervisor (kvm) instead of real hardware so you get a few devices implemented through virtio and run on top of that.

His blog post on fleet is at http://www.redecho.org/2015/10/01/system-programming-is-fun-...

Hmm would be fun to add something like Lisp or Erlang on top of that and have the OS boot to the REPL :)

Edit: There is a Erlang project already: http://erlangonxen.org/ Edit2: wrong link...

Not to C programmers. ;) Most of those projects are dead now. However, I think this one was semi-usable and might still be:

https://news.ycombinator.com/item?id=8955140

Not all that useful and the code quality is mediocre. gas has macros to reduce boilerplate to nearly nothing. String primitives have already been written in portable C with one liners (see Klee on github). Assembly should only be for things primitive bootstrapping, really weird alignment issues (such as to avoid F00F) or crazy but necessary tricks like stackless operation. Higher level is your friend, low level is "I have a hammer" job security. (I know the area around p. 1800-2200 of the Intel IA-32 manual too well, I'll probably never forget PDE and PDT layouts, GDTR-null self-hosting.)

A more interesting trick of exokernel frameworks would be to provide a consistent interface across platforms such as video, input, storage and threads made easily accessible like QNX and others have done.

I'd be happy to hear your suggestions for improving the code. I've done lots of assembly programming and firmware development over the years, but rarely on x86, and this project was the first time I've used the GNU assembler. It was a learning experience, and that's part of the reason I decided to share it.

I actually wrote parts of this library in C at first, but ported them down to assembler once I got them working, because it felt more elegant to divide my project cleanly into a 'runtime' library written in assembler and a 'kernel' program written in C. A matter of taste, I suppose. The use of assembly doesn't really create a maintenance burden as the target architecture isn't changing and the library already does everything it needs to.

Interesting to see where this will go. I believe the common things to choose when one wants C on minimal runtime are RTEMS and eCOS:

https://www.rtems.org/

http://ecos.sourceware.org/about.html

I've always been surprised they weren't modified for use in VM's in the JeOS-type deployments. I'm sure some components like network stack could use some security review but I don't think that's why they were ignored. eCos's configuration options were particularly a strength as you could keep just what you wanted.

Something that would be really useful: a freestanding snprintf implementation.

There are a few self-contained snprintf implementations, such as this one: http://www.ijs.si/software/snprintf

Some porting work may be required for freestanding/bare metal platforms.

I've used https://github.com/h2o/qrintf before which replaces many snprintf usages with standard C code at compile time

Pure64 from Return Infinity sounds like something similar for 64-bit systems (sans C headers): https://github.com/ReturnInfinity/Pure64

Should check out my bare-metal unit test project targeting microcontrollers. Goal is to not use things like pipe()/fork()/malloc() etc.

https://github.com/kylemanna

Agrh, https://github.com/kylemanna/nanotest

A bit limited, as it's only for 32 bits x86, something the topic doesn't mention.

There is no example of supported hardware, so at first glance It seems it would only be useful on old hardware, or Soekris-like boxes...

From his other project metioned by baruch:

"Requiring each program to include drivers for every possible hardware device would be madness, and slow madness since device emulation is tricky and expensive. These programs are never going to be run on bare metal anyway, so I’m going to ignore all legacy PC devices and define the ‘fleet’ system interface a consisting solely of virtio devices. These devices all have a simple, standardized IO interface, so it should be no problem to build drivers for six or eight of them into my kernel-library. I’ll offer an efficient low-level I/O API for nonblocking DMA transfers. All the clunky, synchronous, blocking C APIs can be implemented on top of that."

Xvisor [ http://xhypervisor.org/ ] does that (plus many other things) -- I do like the virtio driver layer a lot; however in the case of Xvisor, you also get CPU virtualisation as well as IO drivers -- it's also portable across quite a few platforms.

Reply on news.ycombinator.com