Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
OSNews, Generic OSes The just released version 12.08 of the Genode OS Framework comes with the ability to run Genode-based systems on ARM hardware without an underlying kernel, vastly improves the support for the NOVA hypervisor, and adds device drivers for the OMAP4 SoC. Further functional additions are a FFAT-based file system service, the port of the lighttpd web server, and support for on-target debugging via GDB.
Thread beginning with comment 532003
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Good Progress
by nfeske on Fri 24th Aug 2012 15:17 UTC in reply to "Good Progress"
nfeske
Member since:
2009-05-27

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?

Reply Parent Score: 2

RE[2]: Good Progress
by jayrulez on Fri 24th Aug 2012 16:58 in reply to "RE: Good Progress"
jayrulez Member since:
2011-10-17

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.

Reply Parent Score: 2

RE[3]: Good Progress
by nfeske on Fri 24th Aug 2012 20:31 in reply to "RE[2]: Good Progress"
nfeske Member since:
2009-05-27

Apparently, the redundancies between the microkernel and the first user-land component (mostly called root task) have been somehow overlooked for years now. Not just in the context of Genode but in multi-server OS projects in general. I guess the reason is that both kind of programs used to be developed by distinct groups of people. Boldly generalizing, I think that kernel developers love to stay in kernel land. Their view is somehow narrowed to the kernel API and hardly extend to a holistic system. On the other hand, user-land developers do not challenge kernel APIs too much (similar to how most software developers rarely question the hardware interfaces underneath their software).

Personally, I find the result of the base-hw experiment quite fascinating. It shows that dissolving the barrier between thinking in categories of kernel land and user land bears the opportunity for simplifying the overall architecture.

I share your observation about several of the base platforms. The motivation for keeping them around slightly differ from kernel to kernel. For Codezero, we are still hoping for a relaunch of the kernel as an Open-Source project. Pistachio is actually still maintained. For all of those kernels, there are also common reasons to not abandon them.

First, its beneficial for Genode's API design. Each kernel poses different challenges with regard to implementing the API. By accommodating a variety of kernel interfaces, we constantly reassure the portability of the framework and force ourself to find clean solutions that work across all of the kernels.

Second, having an arsenal of kernels at our disposal is just great for cross-correlating the behaviour of the system during debugging. Many bugs can be tracked down by just looking at the differences of executing the same scenario on different platforms. In fact, at Genode Labs we are constantly switching between the kernels including the ancient L4/Fiasco kernel. As a bonus, several of the kernels offer unique debugging features, which become pretty handy from time to time.

Third, maintaining support for an already supported base platform is cheap. It comes down to maintaining approximately 2000-3000 lines of code per kernel. For a kernel that won't move, the maintenance costs are almost zero (except for changes of the Genode API).

Reply Parent Score: 2

RE[2]: Good Progress
by Alfman on Fri 24th Aug 2012 18:00 in reply to "RE: Good Progress"
Alfman Member since:
2011-01-28

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?

Reply Parent Score: 2

RE[3]: Good Progress
by nfeske on Fri 24th Aug 2012 19:48 in reply to "RE[2]: Good Progress"
nfeske Member since:
2009-05-27

For running Genode on x86 in general, there is no urgent need to have this architecture covered by base-hw. There are several other kernels among Genode's supported base platforms that support x86 just fine, i.e., NOVA.

Thank you for having taken the time to study the release notes in such detail.

The paragraph you cited refers to the libc. Before the change, the mentioned functions had been mere dummy stubs. Now, they do something meaningful. The lock is locally within the process. The kernel doesn't know anything about the lock nor is it directly involved in handling the actual read/write/lseek operation. Please remember that we are using a microkernel-based architecture where I/O is performed by user-level components rather than the kernel.

Is one lock for pread/pwrite per process a bottleneck? This is a good question, which is quite hard to answer without having a workload that heavily uses these functions from multiple threads. As long as many processes contend for I/O or the workload is generally bounded by I/O, this is not a scalability issue.

For multi-threaded POSIX applications that call those functions concurrently, however, I agree that the lock per process could be replaced by a lock per file descriptor to improve SMP scalability. I couldn't name such an application from the top of my head, though. Do you have an example that would be worthwhile to investigate? We may change the locking once we see this becoming a real issue rather than a speculative one. Until then, it is just nice to have the functional gap in Genode's libc closed without the risk of introducing race conditions.

Reply Parent Score: 2