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

Jon Taylor

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....


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks