Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#15 GGI 3.0: Drill, baby drill - through the "syscall wall"

open
nobody
None
5
2011-10-17
2011-10-17
Jon Taylor
No

In principle, there is no reason why GGI componentry cannot handle lower-level system operations, below the level of a syscall interface like POSIX or Win32. Once a passable libdl analogy and a persistent storage medium are established as a given, we could imagine such thing as:

* LibScheduler with sublibs for each scheduling type
* LibVFS with sublibs for each type of filesystem (and even a ext2 sublib with helperlibs for ext3/4)
* LibTCP with a huge mix of sublibs and helpers for all the hundreds of TCP/IP protocols
* LibIRQ with various types of bottom-half handlers and interrupt distributior target chain meta-libs
* LibIPC with componentry to implement mutexes, semaphores, critical sections, monitors, etc etc.

All that would be needed after this is to use U-Boot to allocate the storage, load the library binaries, and kick off a initial program which would load and execute using LibIRQ. Everything would be driven up off that, all the way to (for example) a LibPOSIX which would boot a traditional UNIX-style environment for legacy support.

GGI and the meta-master-control code environment is a system programmer's dream, AFAIACS. Maybe someday we will see it actualized, possibly on top of something like Xen. Until then....

Discussion