port a libc or make one from scratch?
Re: port a libc or make one from scratch?
I like that my distro doesn't need to pull 600 packages whenever libc has a security patch.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
Re: port a libc or make one from scratch?
Perhaps not in 2011, but with version 1.8 they introduced the Go plugin system to allow dynamic loading of modules.eekee wrote:Yeah, but they wouldn't even put dynamic linking in Golang which went public in 2011.
Good move.
- AndrewAPrice
- Member
- Posts: 2300
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: port a libc or make one from scratch?
I switched from newlib to musl in my non-POSIX OS. Wish me luck.
I found the source layout to be very straight forward. As a hook, I have a syscall() function with a giant switch statement. Currently 99.999999999% unimplemented, but I got printf() working.
I found the source layout to be very straight forward. As a hook, I have a syscall() function with a giant switch statement. Currently 99.999999999% unimplemented, but I got printf() working.
My OS is Perception.
Re: port a libc or make one from scratch?
Have fun Andrew!
I think I've got Thompson and co. figured out. Unix was a multiuser system in 64 KB, if I remember right. (Maybe 64 Kwords = 128 KB. Maybe less on the initial PDP-8.) To switch tasks, it wrote the entire program memory to disk and read in the next task's memory. Under those circumstances, I think diving tasks between little programs was a good idea, and shared libraries would have been a liability. What if one user was typesetting, another compiling a program, and a third working with, I don't know... simulating a telephony problem? Why they stuck with it is a bit harder to figure out, but I gather Ken Thompson actually couldn't get on with complexity.
I think I've got Thompson and co. figured out. Unix was a multiuser system in 64 KB, if I remember right. (Maybe 64 Kwords = 128 KB. Maybe less on the initial PDP-8.) To switch tasks, it wrote the entire program memory to disk and read in the next task's memory. Under those circumstances, I think diving tasks between little programs was a good idea, and shared libraries would have been a liability. What if one user was typesetting, another compiling a program, and a third working with, I don't know... simulating a telephony problem? Why they stuck with it is a bit harder to figure out, but I gather Ken Thompson actually couldn't get on with complexity.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie