To read all comments associated with this story, please click here.
Thanks for your encouraging words!
Regarding your question about supporting CPU architectures other than ARM for the base-hw platform, there is a rough plan to incorporate MicroBlaze support and thereby displacing the original base-mb platform. There was also a conversation on the mailing list about supporting OpenRISC via base-hw. But those lines of work are not definite. Even though the base-hw concept would principally be applicable to x86, there is currently no plan to pursue this direction. The current focus is certainly ARM.
Which architecture have you had in mind?
I am concerned about the duplication of efforts to manage resources in the kernel and core when using the other platforms.
Consequently, we found several information replicated without a clear benefit. With this comes a seemingly significant redundancy of code for data structures, allocators, and utility functions. Furthermore, there exists a class of problems that must be solved by the kernel and core alike. In particular the resource management of dynamically allocated in-kernel objects respectively in-core objects. Whereas core uses Genode's resource-trading concept to solve this problem, most kernels lack a good solution for the management of in-kernel resources and are consequently prone to resource exhaustion problems.
Is there any plan to to address that problem base platforms other than base-hw?
Another area of concern is the supported base platforms. Some of the supported kernels do not seem to be developed anymore or are no longer open source. E.g. Codezero, Pistachio, OKL4 and the old Fiasco. Also, Codezero also seem to offer a subset of the features of Fiasco.OC.
From what I understand, the wide variety of kernels helps to produce ideal design decisions in genode that are applicable across platforms. Is there any other merit in continuing to develop genode on those platforms?
Congratulations on the new release and the detailed release notes. They are always interesting to read. Genode is an excellent project and I am looking forward to seeing it widely deployed in the future.
Regards.
I think there'd be merit in having base-hw on x86 given the widespread availability of off the shelf hardware.. but of course you gotta focus with what matters to you.
System programming jobs have become rare here, I've always thought it would be so much fun to land a job working on an alternative operating system instead of just doing it as a hobby.
So anyway, back on topic, I read this in your release notes:
"We complemented our C runtime with support for the pread, pwrite, readv, and writev functions. The pread and pwrite functions are shortcuts for randomly accessing different parts of a file. Under the hood, the functions are implemented via lseek and read/write. To provide the atomicity of the functions, a lock guard prevents the parallel execution of either or both functions if called concurrently by multiple threads."
You are implementing these functions (pread/pwrite) with two system calls then? Is there one lock per process, per file descriptor, or something else? Is this lock held in the kernel or in user space? It seems to me like such locks could impose a major synchronization bottleneck on SMP architectures, is there a reason you wouldn't just add new syscalls for pread/pwrite?





Member since:
2007-08-20
It is really encouraging to see continual progress being made on this project. It's nice to see different OS concepts put into practice successfully.
The "base-hw" addition is very interesting. Are you planning on adding other CPU architectures also?
The NOVA hypervisor work is very intriguing as well. Especially this part:
Keep up the good work!
Edited 2012-08-23 20:04 UTC