Hello all,
I would like to bring up the discussion of whether our project should apply for GSoC this year. Jakub Jermar (HelenOS) encouraged me to do so and I like this idea. The application of mentoring organizations is open until 9th of March:
http://google-opensource.blogspot.com/2012/02/mentoring-organization-applica...
I propose to select 5 working topics as potential GSoC projects, taking our "challenges" and "roadmap" as inspiration:
http://genode.org/about/challenges http://genode.org/about/road-map
Of course, we are open to further suggestions. If you have one, please go ahead and tell us! For each of the topics, we will need to provide a rationale about
* Why do we think it is a good idea to pursue the work, * Where it fits into the scope of our project, and * Why we think it is feasible to achieve the goal during the summer.
Furthermore, we should try to plan ahead working steps as far as we see them. For doing this, the GitHub issue tracker would be the ideal place.
One particular topic that Jakub brought up is combining Genode with the HelenOS kernel (called SPARTAN). Personally, I think this would be a technically intriguing topic and also a good opportunity to cultivate the relationship between the HelenOS team and Genode.
So what do you think? Do you agree that GSoC participation is a good idea? Are you interested in playing a role in it, as mentor, or student participant? I would be glad about feedback from you.
Cheers Norman
Yes. i vouch for it. However, i have i'm still in doubt regarding the quality of the code produce by the students. Well, not undermining them, however, before merging the GSoC code with the master, i highly recommend a quality check or defined a quality standard so they can comply with it.
On 29.02.2012 13:23, Norman Feske wrote:
So what do you think? Do you agree that GSoC participation is a good idea? Are you interested in playing a role in it, as mentor, or student participant? I would be glad about feedback from you.
I think it's a good idea to join GSoC. Especially to get new persons involved in our development work. Also I would like to participate at least as a co-mentor, especially with respect to the HelenOS/Genode task, because I'm highly interested in what that base-helenos repository will look like :-).
Further feasible tasks for that limited time-span might be the issues:
#113 block cache #114 virtual NAT
because they are somehow a bit more self-contained.
And what about building a "Go" runtime for Genode, or is that to much bootlicking ;-)
Hi,
first, I'm definitely available for mentorship as I expect GSoC a valuable experience and maybe a booster for our project in sense of contributions and attention.
Additionally, I also vote for
On Wed, Feb 29, 2012 at 04:00:10PM +0100, Stefan Kalkowski wrote:
#113 block cache #114 virtual NAT
Would it be to daring to propose implementation/port of Intel Wireless (iwlagn) plus WPA supplicant?
Greets
Am Mittwoch, den 29.02.2012, 16:55 +0100 schrieb Christian Helmuth:
Hi,
first, I'm definitely available for mentorship as I expect GSoC a valuable experience and maybe a booster for our project in sense of contributions and attention.
Additionally, I also vote for
On Wed, Feb 29, 2012 at 04:00:10PM +0100, Stefan Kalkowski wrote:
#113 block cache #114 virtual NAT
Would it be to daring to propose implementation/port of Intel Wireless (iwlagn) plus WPA supplicant?
That may be a huge task. What about porting a non-trivial application to Noux, e.g. binutils?
Julian
Hi,
Would it be to daring to propose implementation/port of Intel Wireless (iwlagn) plus WPA supplicant?
That may be a huge task. What about porting a non-trivial application to Noux, e.g. binutils?
My gut also tells me that the whole Wifi package is certainly too heavy to lift during a GSoC project. But maybe we would split this task into smaller pieces?
Binutils and GCC are actually almost there (just take a look into the ports repository). According to our road map, those tools will be ready to use on Genode no later than in August. So this would rule out this topic anyway.
Another project idea I had today was a statistical profiling/tracing tool. As application scenarios grow in complexity, I expect that we will increasingly ask the question, through which window all our CPU cycles went. It would be great to have tooling support that gives us the answer. Honestly, I don't know where to start for investigating this topic (should we look into gprof? dtrace? ?).
Cheers Norman
Am Mittwoch, den 29.02.2012, 21:48 +0100 schrieb Norman Feske:
Hi,
Would it be to daring to propose implementation/port of Intel Wireless (iwlagn) plus WPA supplicant?
That may be a huge task. What about porting a non-trivial application to Noux, e.g. binutils?
My gut also tells me that the whole Wifi package is certainly too heavy to lift during a GSoC project. But maybe we would split this task into smaller pieces?
Binutils and GCC are actually almost there (just take a look into the ports repository). According to our road map, those tools will be ready to use on Genode no later than in August. So this would rule out this topic anyway.
Cool. Didn't notice. What about Emacs? :-D Or support for any reasonable "safe" language that is not C++ to write native Genode applications.
Another project idea I had today was a statistical profiling/tracing tool. As application scenarios grow in complexity, I expect that we will increasingly ask the question, through which window all our CPU cycles went. It would be great to have tooling support that gives us the answer. Honestly, I don't know where to start for investigating this topic (should we look into gprof? dtrace? ?).
Whole system statistical profiling might not be possible without kernel support, which makes this hard given the number of kernels Genode runs on.
Julian
Whole system statistical profiling might not be possible without kernel support, which makes this hard given the number of kernels Genode runs on.
well, the CPU session interface provides a facility to query thread-state information including the program counter. By virtualizing this interface, the program counter of all CPU sessions of a sub system could be sampled quite easily. But the question is what to do with this data? One would need tooling support to visualize the distribution of the sampled program-counter values, showing the function names, or presenting backtraces in an expressive manner.
Norman
Hey,
On Wed, Feb 29, 2012 at 09:48:34PM +0100, Norman Feske wrote:
That may be a huge task. What about porting a non-trivial application to Noux, e.g. binutils?
My gut also tells me that the whole Wifi package is certainly too heavy to lift during a GSoC project. But maybe we would split this task into smaller pieces?
Sounds like a good idea (even if we not go for GSoC with the challenge). I'll think about it.
I also read again through http://genode.org/about/challenges and http://genode.org/about/road-map. For me, one major goal appropriate to tackle during the summer is block-device encryption and I want to promote it hereby. To use Genode every day in Genode Labs it's crucial to protect the confidentiality of some information that's part of the Genode code base, e.g., emails and reports. There are several expansion stages imaginable to reach the goal and the basic building blocks (block-device interface, ATA/SATA driver for Qemu) are already in place.
BTW some of the challenges on our agenda (including iwlagn) depend on the availability of test hardware. What do you think, does this render these tasks inappropriate for GSoC?
Greets
OMG, what a typo!
On Thu, Mar 01, 2012 at 08:49:16AM +0100, Christian Helmuth wrote:
To use Genode every day in Genode Labs it's crucial to protect the confidentiality of some information that's part of the Genode code base, e.g., emails and reports.
Certainly, I meant "information that's _not_ part of the Genode code base". Sometimes I should reread my emails twice. Sorry.
Hi,
I also read again through http://genode.org/about/challenges and http://genode.org/about/road-map. For me, one major goal appropriate to tackle during the summer is block-device encryption and I want to promote it hereby. To use Genode every day in Genode Labs it's crucial to protect the confidentiality of some information that's part of the Genode code base, e.g., emails and reports. There are several expansion stages imaginable to reach the goal and the basic building blocks (block-device interface, ATA/SATA driver for Qemu) are already in place.
I agree that this topic is nice because it is almost self-contained (similar to the block cache topic suggested by Stefan). So it can be tackled without knowing many architectural details or even seeing the big picture.
That said, I am uncertain about the motivation you gave. From a student's point of view, our needs at Genode Labs may not provide enough incentive to go for it. If I were a student, I would prefer working on a topic that is somehow related to my personal (or more general) needs. One way of making this topic more convincing may be to take block-level encryption just as a concrete example to work on, but define the topic in a more general way. For example "cryptography on Genode". By framing the topic this way, the student can explore many interesting technologies (e.g., random-number generators, OpenSSL, GnuTLS, SSH, GnuGPG) in the context of Genode. The implementation of the block encryption component would be merely a side effect.
BTW some of the challenges on our agenda (including iwlagn) depend on the availability of test hardware. What do you think, does this render these tasks inappropriate for GSoC?
I would not rule them out. If there is someone who is highly interested in working on a sophisticated topic such as Intel Wireless support and already has a track record in working on similar things, we should try to accommodate him/her by providing test hardware. But for a student without a clear skill set, I would propose a topic that does not involve such additional expenses. I.e., a topic that can be carried out natively on Linux or on Qemu.
Cheers Norman
Hello Althaf,
Yes. i vouch for it. However, i have i'm still in doubt regarding the quality of the code produce by the students. Well, not undermining them, however, before merging the GSoC code with the master, i highly recommend a quality check or defined a quality standard so they can comply with it.
don't worry about that too much. All patches that go into mainline have to pass the eagle eyes of long-term Genode developers.
We cannot expect students to produce product-quality code from day one. But we can try to bring them on the right track. If I understand correctly, this is the actual point of GSoC. Even in the event that we won't use the resulting code as is, the outcome of the student's work (e.g., in the form of a working prototype, or in the form of the realization that a particular approach does not work as expected) would be beneficial for both the student and us.
Cheers, Norman
Hi,
On Thu, Mar 01, 2012 at 09:58:13AM +0100, Norman Feske wrote:
That said, I am uncertain about the motivation you gave. From a student's point of view, our needs at Genode Labs may not provide enough incentive to go for it. If I were a student, I would prefer working on a topic that is somehow related to my personal (or more general) needs.
You're right, what I wrote are _my professional_ needs. My personal need that definitely overlaps with other developers is: privacy. IMO this shall be a strong motivation factor in the present computing world as it is for the whole Genode project.
One way of making this topic more convincing may be to take block-level encryption just as a concrete example to work on, but define the topic in a more general way. For example "cryptography on Genode". By framing the topic this way, the student can explore many interesting technologies (e.g., random-number generators, OpenSSL, GnuTLS, SSH, GnuGPG) in the context of Genode. The implementation of the block encryption component would be merely a side effect.
Two remarks about the two components of your paragraph:
* If I understand you correctly, you propose to broaden the topic to anything related to cryptography in Genode, which I'd like to avoid. The tasks for summer should be tailored for the expected time frame and also address a specific topic. Additionally, we should keep the trailing remark about our openness to proposals.
* I don't think block-device encryption can be solved as a side effect as it must be investigated thoroughly and implemented with care. The history of LUKS and its predecessors for example spans over years.
I would not rule them out. If there is someone who is highly interested in working on a sophisticated topic such as Intel Wireless support and already has a track record in working on similar things, we should try to accommodate him/her by providing test hardware. But for a student without a clear skill set, I would propose a topic that does not involve such additional expenses. I.e., a topic that can be carried out natively on Linux or on Qemu.
Agree.
Regards
On 1 March 2012 14:37, Norman Feske <norman.feske@...1...> wrote:
Hello Althaf,
Yes. i vouch for it. However, i have i'm still in doubt regarding the quality of the code produce by the students. Well, not undermining them, however, before merging the GSoC code with the master, i highly recommend a quality check or defined a quality standard so they can comply with it.
don't worry about that too much. All patches that go into mainline have to pass the eagle eyes of long-term Genode developers.
We cannot expect students to produce product-quality code from day one. But we can try to bring them on the right track. If I understand correctly, this is the actual point of GSoC. Even in the event that we won't use the resulting code as is, the outcome of the student's work (e.g., in the form of a working prototype, or in the form of the realization that a particular approach does not work as expected) would be beneficial for both the student and us.
This is an insight i didn't have. yes you are right. More over, well, this student X might continue to improve the implementation, on later stages.
On Wed, 29 Feb 2012 16:00:10 +0100, Stefan Kalkowski <stefan.kalkowski@...1...> wrote:
On 29.02.2012 13:23, Norman Feske wrote:
So what do you think? Do you agree that GSoC participation is a good idea? Are you interested in playing a role in it, as mentor, or student participant? I would be glad about feedback from you.
I might be tempted to apply as a student to GSoC for Genode.
And what about building a "Go" runtime for Genode, or is that to much bootlicking ;-)
That is actually quite feasible. The hard issue is interfacing with Genode specific interfaces done in C++ since there is little support for C++ integration in Go. But porting the basic runtime should be fairly easy.
There are two runtimes the gccgo one which requires libpthreads for goroutines and the gc one which is more popular but also more eccentric.
There are ports of the gccgo runtime to L4 side of things by Daniel Mueller and myself, and I have done some porting of gc to Plan9.
If one needs just a higher level language on top of Genode then using Lua is trivial (if someone wants it please mail me) and there are multiple solutions to Lua<->C++ interfacing.
Block device encryption is very interesting and important. I think that especially a solution that would combine logical volume management (like lvm) with encryption would be interesting. (i.e. different keys for different logical volumes and also encrypt the metadata).
- Taru Karttunen
Hi,
Two remarks about the two components of your paragraph:
- If I understand you correctly, you propose to broaden the topic to anything related to cryptography in Genode, which I'd like to avoid. The tasks for summer should be tailored for the expected time frame and also address a specific topic. Additionally, we should keep the trailing remark about our openness to proposals.
when thinking more about it, you are certainly right. We should try to define the project as tangible as possible.
Cheers Norman
Hello Taru,
I might be tempted to apply as a student to GSoC for Genode.
great to know there is actual interest in having us participate. So we should definitely go for it! .-)
That is actually quite feasible. The hard issue is interfacing with Genode specific interfaces done in C++ since there is little support for C++ integration in Go. But porting the basic runtime should be fairly easy.
There are two runtimes the gccgo one which requires libpthreads for goroutines and the gc one which is more popular but also more eccentric.
There are ports of the gccgo runtime to L4 side of things by Daniel Mueller and myself, and I have done some porting of gc to Plan9.
If one needs just a higher level language on top of Genode then using Lua is trivial (if someone wants it please mail me) and there are multiple solutions to Lua<->C++ interfacing.
To have a safer systems language (something that Julian may have had in mind) is a quite different topic than having a scripting facility. If we go for a particular runtime, it would help to sketch its designated use within Genode beforehand.
With regard to safe systems languages, I am personally inclined towards the D programming language. But Go and Rust are certainly also interesting topics to explore. Each of those may attract a different user base.
BTW, speaking of safe systems languages, there is already a certain degree of ADA/Spark support in Genode:
http://genode.org/documentation/release-notes/9.11#Zero-footprint_runtime_fo...
Block device encryption is very interesting and important. I think that especially a solution that would combine logical volume management (like lvm) with encryption would be interesting. (i.e. different keys for different logical volumes and also encrypt the metadata).
Sounds interesting. Good that the topic is deemed relevant to Genode users outside Genode Labs as well.
Thanks for your feedback! It is very much appreciated.
Norman
-
Althaf -
Christian Helmuth -
Julian Stecklina -
Norman Feske -
Stefan Kalkowski -
Taru Karttunen