Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
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.
Permalink for comment 532275
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2009-05-27
You are welcome! :-)
Indeed, the code looks similar to the snippet you posted. See here:
https://github.com/genodelabs/genode/blob/master/libports/src/lib/li...
Fortunately, your concerns do not apply for Genode. In Genode's libc, the seek offset is not held at the file system but local to the process within the libc. The file-system interface is designed such that the seek offset is passed from the client to the file system with each individual file-system operation. The seek value as seen at libc API level is just a value stored alongside the file descriptor within the libc. Therefore, lseek is cheap. It is just a library call updating a variable without invoking a syscall.
Your example does indeed subvert the locking scheme. But as Genode does not provide fork(), it wouldn't work anyway. ;-)
Btw, if programs are executed within the Noux runtime (see [1]), lseek is actually an RPC call to the Noux server. So the pread/pwrite implementation carries an overhead compared to having pread/pwrite as first-class operations. So there is room for optimization in this case.
[1] http://genode.org/documentation/release-notes/11.11#OS-level_Virtua...
Given all the steps that are involved in a single read I/O operation, however, I am uncertain about the benefit of this specific optimization. To prevent falling into the premature-optimization trap, I'd first try to obtain the performance profile of a tangible workload. Another reason I'd be hesitant to introduce pread/pwrite as first-class operations into Noux is that in general, we try to design interfaces to be as orthogonal as possible. Thanks to this guideline, the Noux server is a cute little component of less then 5000 LOC. Introducing pread/pwrite in addition to read/write somehow spoils this principle and increases complexity.
Thanks for the pointer to the database engine. This might be a good starting point for a workload to be taken as reference when optimizing for performance and scalability.