Re: Participating in Google Summer of Code

[Samuel Thibault]

Hello,

ABHINAV C YADAV, le mar. 07 mars 2023 22:35:07 +0530, a ecrit:
> I would like to know more about this, could you please assist me?

We have put information on:

https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/

Samuel

Participating in Google Summer of Code

[ABHINAV C YADAV]

Dear sir,

I'm Abhinav C Yadav, a student from India. I'd like to work on porting Rust
to GNU/Hurd as part of the Google Summer of Code project.

I would like to know more about this, could you please assist me?

Thank you

Re: Google Summer of Code

[Almudena Garcia]

> That's not true, otherwise noone would use agile software development
> with OOP. You have a very rigid, almost V-model way to think about this.

Yes, Maybe It's not necessary an exhaustive analysis. But, anyway, It's
necessary to define what is our objective, define an ideal architecture
(drawing if necessary), although this could change during the development.
This can help us to set a roadmap to this objective, instead repeat the
refactor many times until agree the result.

> Also you're focusing on OOP, while to me, it's only one of the elements
> required for such a project. And all these requirements are driven by a
> single motivation : to reduce maintenance costs. The Hurd is developped
> by a very small group of people, very sporadically, but has virtually
> no deadline constraints. Event the GSoC deadline doesn't matter that
> much since, in the end, mentors are the ones who evaluate your work, and
> it can easily be decided that the result is a success even if it didn't
> meet all the initial conditions. As a result, it's even more important
> than in other projects that original code be as good as it can get.

Ok, I agree with this.

> Mach code is in essence OOP, something you're throwing out the window
> for no good reason.

I tried to add my code in the current Mach structure.
I wasn't clear about how to architecture the code, so I find a simple
implementation with functions (but dirty, in fact)

> Mach is in essence portable, something you also
> decided to forego without much thought.

I was afraid about add new structure which could broken the code, so I
simply tried to fit the new data in the Mach structures.


> Yes, Mach code has some extern
>variables, but these concern a handful of global objects only, like
> the kernel task, map and pmap, and that's code from the 80s and there's
> no reason to continue that trend.

Yes, I agree, and even this is not the only bad practice. I see many
#define macros replacing C functions, which difficults the debugging of the
code. Some of these #define could be replaced by inline functions.
There are also many very long functions, sometimes with a dirty logic
(check thread_setrun() in kern/sched_prim.c), which could be a good
candidate to refactor.

> And without reducing the individual complexity of the functional
> modules involved, you won't be able to master what you're doing.
> And my requirements to work on this project have everything to do with
> reducing that complexity. It's also important to make it easy for
> other people to work on that code.

Ok, It's a good idea.

I like your ideas, now I want to define a more specific objective, and a
little roadmap.

El mié., 5 feb. 2020 a las 11:49, Richard Braun ()
escribió:

> On Wed, Feb 05, 2020 at 10:18:35AM +0100, Almudena Garcia wrote:
> > To do a "serious work" as OOP, It's necessary to think about the current
> > work, separating the pieces of the project, thinking what relationship
> will
> > be between the pieces... Write empty code structures, without a previous
> > rethinking about the final architecture and structure of this code, can
> > cause even more problems than current "dirty" design.
>
> That's not true, otherwise noone would use agile software development
> with OOP. You have a very rigid, almost V-model way to think about this.
>
> Also you're focusing on OOP, while to me, it's only one of the elements
> required for such a project. And all these requirements are driven by a
> single motivation : to reduce maintenance costs. The Hurd is developped
> by a very small group of people, very sporadically, but has virtually
> no deadline constraints. Event the GSoC deadline doesn't matter that
> much since, in the end, mentors are the ones who evaluate your work, and
> it can easily be decided that the result is a success even if it didn't
> meet all the initial conditions. As a result, it's even more important
> than in other projects that original code be as good as it can get.
>
> Mach code is in essence OOP, something you're throwing out the window
> for no good reason. Mach is in essence portable, something you also
> decided to forego without much thought. Yes, Mach code has some extern
> variables, but these concern a handful of global objects only, like
> the kernel task, map and pmap, and that's code from the 80s and there's
> no reason to continue that trend.
>
> > But these tasks are too long for a GSOC. I'm really interested in GSOC,
> but
> > the OOP objective is too ambitious for It.
>
> They're not "tasks". They're requirements for success, especially for
> something as difficult as correct concurrent code with shared memory
> involved. They're not work in a sequence of coding sessions, they're
> part of all coding sessions. What's ambitious is the project itself,
> namely SMP. Well be ambitious, or don't.
>
> > So, I prefer continue with my current code, doing simpler refactors to
> ease
> > the future redesign, but without stop the current objectives (scheduler
>

Re: Google Summer of Code

[Richard Braun]

On Wed, Feb 05, 2020 at 10:18:35AM +0100, Almudena Garcia wrote:
> To do a "serious work" as OOP, It's necessary to think about the current
> work, separating the pieces of the project, thinking what relationship will
> be between the pieces... Write empty code structures, without a previous
> rethinking about the final architecture and structure of this code, can
> cause even more problems than current "dirty" design.

That's not true, otherwise noone would use agile software development
with OOP. You have a very rigid, almost V-model way to think about this.

Also you're focusing on OOP, while to me, it's only one of the elements
required for such a project. And all these requirements are driven by a
single motivation : to reduce maintenance costs. The Hurd is developped
by a very small group of people, very sporadically, but has virtually
no deadline constraints. Event the GSoC deadline doesn't matter that
much since, in the end, mentors are the ones who evaluate your work, and
it can easily be decided that the result is a success even if it didn't
meet all the initial conditions. As a result, it's even more important
than in other projects that original code be as good as it can get.

Mach code is in essence OOP, something you're throwing out the window
for no good reason. Mach is in essence portable, something you also
decided to forego without much thought. Yes, Mach code has some extern
variables, but these concern a handful of global objects only, like
the kernel task, map and pmap, and that's code from the 80s and there's
no reason to continue that trend.

> But these tasks are too long for a GSOC. I'm really interested in GSOC, but
> the OOP objective is too ambitious for It.

They're not "tasks". They're requirements for success, especially for
something as difficult as correct concurrent code with shared memory
involved. They're not work in a sequence of coding sessions, they're
part of all coding sessions. What's ambitious is the project itself,
namely SMP. Well be ambitious, or don't.

> So, I prefer continue with my current code, doing simpler refactors to ease
> the future redesign, but without stop the current objectives (scheduler
> synchronization, and load system with cpu 0 as bound processor).

You'll just waste a lot of time getting there, if at all, with that
approach. Refactors are only good if applied on code that is already
fit for incremental change. Your existing SMP implementation is not.
It needs a complete rework. The fact that you were never able to
understand why it's not able to handle more than 2 CPUs is a frightnening
indicator of that state. Imagine the day you'll be facing apparently
random crashes that can occur almost right away or after hours of run
time. Without completely mastering what you're doing, it's almost
guaranteed that you won't be able to fix those, let alone identify
them. And without reducing the individual complexity of the functional
modules involved, you won't be able to master what you're doing.
And my requirements to work on this project have everything to do with
reducing that complexity. It's also important to make it easy for
other people to work on that code.

I wouldn't be insisting so much on these points if I didn't think they
were critically important. All this is not new. You're a student, so
learn from it.

-- 
Richard Braun

Re: Google Summer of Code

[Almudena Garcia]

> I don't think that you need to apologize for your opinion.
Thanks. I don't want you are angry with me by this reason. I simply want to
explain my situation about this project.

> I will say that Richard is *very* knowledgeable.
Yes, I know. The ideas about to use OOP structure in the code, add tests,
atomic operations... are excellent, but I don't agree with the way to do It.

To do a "serious work" as OOP, It's necessary to think about the current
work, separating the pieces of the project, thinking what relationship will
be between the pieces... Write empty code structures, without a previous
rethinking about the final architecture and structure of this code, can
cause even more problems than current "dirty" design.

But these tasks are too long for a GSOC. I'm really interested in GSOC, but
the OOP objective is too ambitious for It.

Despite this, some of his advices can be applied in the current design:
separate apic_id to a new structure (to avoid mix machine-specific and
non-specific structures), remove some "extern" calls...

So, I prefer continue with my current code, doing simpler refactors to ease
the future redesign, but without stop the current objectives (scheduler
synchronization, and load system with cpu 0 as bound processor).




El mar., 4 feb. 2020 a las 16:13, Joshua Branson ()
escribió:

>
> I don't think that you need to apologize for your opinion.  I will say
> that Richard is *very* knowledgeable.  Any hints that you can get from
> him are bound to be useful.
>
> --
> Joshua Branson
> Sent from Emacs and Gnus
>

Re: Google Summer of Code

[Joshua Branson]

I don't think that you need to apologize for your opinion.  I will say
that Richard is *very* knowledgeable.  Any hints that you can get from
him are bound to be useful.

--
Joshua Branson
Sent from Emacs and Gnus

Re: Google Summer of Code

[Almudena Garcia]

> I think any work that is meant to last and ends up in a form that
> isn't fit for long term maintenance isn't serious work.

I'm sorry, but I continue seeing the OOP redesign as a long term objective,
but not appropriated as GSOC main objective.
But It's possible to do little refactors to prepare the work for a future
fully redesign.

My main objective for this GSOC is improve a bit the code structure, doing
little refactors in functions and structures, and fix the problems with
scheduling and synchronization.

If another person want to be my mentor for this objective, I'll value It.
Thanks, and sorry


El vie., 31 ene. 2020 a las 22:08, Richard Braun ()
escribió:

> On Fri, Jan 31, 2020 at 08:58:41PM +0100, Almudena Garcia wrote:
> > > That's not exactly what I mean. Let's talk on IRC to sort this out.
> >
> > I've not seen you today in freenode, so I'll write my opinion here:
>
> I'm always on IRC, just not in #hurd. You can message me directly.
>
> > I think that a better idea could be to continue the current work with
> easy
> > refactors (change some names, create functions to avoid duplicated code,
> > moved some data (as apic_id) to more correct structures... etc), which is
> > simpler than a fully OOP redesign.
> >
> > what do you think?
>
> I think any work that is meant to last and ends up in a form that
> isn't fit for long term maintenance isn't serious work.
>
> --
> Richard Braun
>

Re: Google Summer of Code

[Richard Braun]

On Fri, Jan 31, 2020 at 08:58:41PM +0100, Almudena Garcia wrote:
> > That's not exactly what I mean. Let's talk on IRC to sort this out.
> 
> I've not seen you today in freenode, so I'll write my opinion here:

I'm always on IRC, just not in #hurd. You can message me directly.

> I think that a better idea could be to continue the current work with easy
> refactors (change some names, create functions to avoid duplicated code,
> moved some data (as apic_id) to more correct structures... etc), which is
> simpler than a fully OOP redesign.
> 
> what do you think?

I think any work that is meant to last and ends up in a form that
isn't fit for long term maintenance isn't serious work.

-- 
Richard Braun

Re: Google Summer of Code

[Almudena Garcia]

> That's not exactly what I mean. Let's talk on IRC to sort this out.

I've not seen you today in freenode, so I'll write my opinion here:

I've been thinking about our conversation some days ago. Although redesign
all SMP code as OOP (adding abstractions for isolate machine-specific
code), is a good idea in the long term, I think that this refactor is a
very big effort, and It's excessive for a 3 months GSOC. The simply design
of this architecture could last more than a year.  So I prefer to avoid
this way

I think that a better idea could be to continue the current work with easy
refactors (change some names, create functions to avoid duplicated code,
moved some data (as apic_id) to more correct structures... etc), which is
simpler than a fully OOP redesign.

what do you think?

El lun., 27 ene. 2020 a las 17:45, Richard Braun ()
escribió:

> On Mon, Jan 27, 2020 at 05:09:38PM +0100, Almudena Garcia wrote:
> > I'm a student, and my knowledge is limited. But, in my previous SMP
> work, I
> > got develop most tasks guided by more experienced developers than me.
> > If any person is able to guide my work, teaching me the most important
> > concepts and solving my questions about this, probably I'm able to do
> this
> > task
>
> That's not exactly what I mean. Let's talk on IRC to sort this out.
> I'm braunr@Freenode.
>
> --
> Richard Braun
>

Re: Google Summer of Code

[Richard Braun]

On Mon, Jan 27, 2020 at 05:09:38PM +0100, Almudena Garcia wrote:
> I'm a student, and my knowledge is limited. But, in my previous SMP work, I
> got develop most tasks guided by more experienced developers than me.
> If any person is able to guide my work, teaching me the most important
> concepts and solving my questions about this, probably I'm able to do this
> task

That's not exactly what I mean. Let's talk on IRC to sort this out.
I'm braunr@Freenode.

-- 
Richard Braun

Re: Google Summer of Code

[Almudena Garcia]

> It will require a lot of work on your side. If you're going to do this,
you need to make sure you are able to
> commit to the task.

I'm a student, and my knowledge is limited. But, in my previous SMP work, I
got develop most tasks guided by more experienced developers than me.
If any person is able to guide my work, teaching me the most important
concepts and solving my questions about this, probably I'm able to do this
task

Thanks


El lun., 27 ene. 2020 a las 13:33, Richard Braun ()
escribió:

> On Mon, Jan 27, 2020 at 10:48:26AM +0100, Almudena Garcia wrote:
> > > Thanks for your interest!  As Joshua wrote: "need to find a Hurd
> > > developer to mentor you".
> >
> > Are there any volunteer for this?
> > I need anyone with knowledge in this area (and with a bit of patience,
> > anyway) because I'm a student, and I've very low knowledge in real
> > operating system development.
> > My current work is here: https://github.com/AlmuHS/GNUMach_SMP
>
> I could, but this is a tough one. It will require a lot of work on your
> side. If you're going to do this, you need to make sure you are able to
> commit to the task.
>
> --
> Richard Braun
>

Re: Google Summer of Code

[Richard Braun]

On Mon, Jan 27, 2020 at 10:48:26AM +0100, Almudena Garcia wrote:
> > Thanks for your interest!  As Joshua wrote: "need to find a Hurd
> > developer to mentor you".
> 
> Are there any volunteer for this?
> I need anyone with knowledge in this area (and with a bit of patience,
> anyway) because I'm a student, and I've very low knowledge in real
> operating system development.
> My current work is here: https://github.com/AlmuHS/GNUMach_SMP

I could, but this is a tough one. It will require a lot of work on your
side. If you're going to do this, you need to make sure you are able to
commit to the task.

-- 
Richard Braun

Re: Google Summer of Code

[Almudena Garcia]

> Yes, and now waiting for Google to decide.  See
> .

Ok, I'll wait for this

> Thanks for your interest!  As Joshua wrote: "need to find a Hurd
> developer to mentor you".

Are there any volunteer for this?
I need anyone with knowledge in this area (and with a bit of patience,
anyway) because I'm a student, and I've very low knowledge in real
operating system development.
My current work is here: https://github.com/AlmuHS/GNUMach_SMP

Thanks by the info

El lun., 27 ene. 2020 a las 10:33, Thomas Schwinge ()
escribió:

> Hi!
>
> On 2020-01-26T20:05:46+0100, Almudena Garcia 
> wrote:
> > Does anyone knows if this year GNU apply to GSOC?
> > The deadline is February 5.
> >
> > https://summerofcode.withgoogle.com/get-started/
>
> Yes, and now waiting for Google to decide.  See
> .
>
>
> > I'm interested in apply to continue my Hurd SMP project
>
> Thanks for your interest!  As Joshua wrote: "need to find a Hurd
> developer to mentor you".
>
>
> Grüße
>  Thomas
>

Re: Google Summer of Code

[Thomas Schwinge]

Hi!

On 2020-01-26T20:05:46+0100, Almudena Garcia  wrote:
> Does anyone knows if this year GNU apply to GSOC?
> The deadline is February 5.
>
> https://summerofcode.withgoogle.com/get-started/

Yes, and now waiting for Google to decide.  See
.


> I'm interested in apply to continue my Hurd SMP project

Thanks for your interest!  As Joshua wrote: "need to find a Hurd
developer to mentor you".


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: Google Summer of Code

[Joshua Branson]

Well I believe that almost always GNU gets accepted as a GSOC mentee
organization.  I suppose you would need to find a Hurd developer to
mentor you.

--
Joshua Branson
Sent from Emacs and Gnus

Google Summer of Code

[Almudena Garcia]

Hi all:

Does anyone knows if this year GNU apply to GSOC?
The deadline is February 5.

https://summerofcode.withgoogle.com/get-started/

I'm interested in apply to continue my Hurd SMP project

Re: Google Summer of Code projects for the GNU C Library.

[Jose E. Marchesi]

On Wed, 26 Feb 2014 10:23:28 +0100, I wrote:
> On Wed, 19 Feb 2014 19:14:45 -0500, "Carlos O'Donell"  
wrote:
> > The GNU Project is participating in GSoC 2014 and have asked
> > individual GNU projects to nominate their own GSoC projects
> > under their umbrella.
> > 
> > We have proposed an initial three projects for the GNU C Library
> > and you can see them here:
> > http://www.gnu.org/software/soc-projects/ideas-2014.html

José, please apply the following patch to ideas-2014.html:

Done.

Re: Google Summer of Code projects for the GNU C Library.

[Thomas Schwinge]

Hi!

On Wed, 26 Feb 2014 10:23:28 +0100, I wrote:
> On Wed, 19 Feb 2014 19:14:45 -0500, "Carlos O'Donell"  
> wrote:
> > The GNU Project is participating in GSoC 2014 and have asked
> > individual GNU projects to nominate their own GSoC projects
> > under their umbrella.
> > 
> > We have proposed an initial three projects for the GNU C Library
> > and you can see them here:
> > http://www.gnu.org/software/soc-projects/ideas-2014.html

José, please apply the following patch to ideas-2014.html:

> I have just added »Implement Missing Interfaces for GNU Hurd«,
> :

> Please review/edit/amend/polish this (please shout if you need to be
> added to ), and then I'll
> soon ask José to also include it on
>  as well as put
> it on/link to it from
> .

diff --git ideas-2014.html ideas-2014.html
index d9fa315..56a5657 100644
--- ideas-2014.html
+++ ideas-2014.html
@@ -232,6 +232,28 @@ for all functions. This work can stop at any point and we 
will have
 made progress against testing the current implementation.
 
 
+Implement Missing Interfaces for GNU 
Hurd
+
+In glibc's Linux kernel port, most simple POSIX interfaces are in fact just 
forwarded to (implemented by) Linux kernel system calls.
+In contrast, in the http://www.gnu.org/software/hurd/glibc.html";>GNU 
Hurd port, the POSIX (and other) interfaces are actually implemented in 
glibc on top of the http://www.gnu.org/software/hurd/hurd/rpc.html";>Hurd RPC protocols.
+A few examples:
+https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/getuid.c";>getuid,
+https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c";>open,
+https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/rmdir.c";>rmdir,
+https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/setresuid.c";>setresuid,
+https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/socketpair.c";>socketpair.
+
+
+
+When new interfaces are added to glibc (new editions of POSIX and similar 
standards, support for new editions of C/C++ standards, new GNU-specific 
extensions), generally https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/execve.c";>ENOSYS 
stubs are added, which are then used as long as there is no real 
implementation, and often these real implementations are only done for the 
Linux kernel port, but not GNU Hurd.
+(This is because most of the contributors are primarily interested in using 
glibc on Linux-based systems.)
+Also, there is quite a backlog of http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing";>missing 
implementations for GNU Hurd.
+
+
+
+In coordination with the mailto:bug-hurd@gnu.org";>GNU Hurd 
developers, you'd work on implementing such missing interfaces.
+
+
 http://www.gnu.org/software/gdb";>GDB
 
 GDB, the GNU Project debugger, allows you to see what is going on
@@ -455,7 +477,7 @@ results.
 Mentor: mailto:l...@gnu.org";>Ludovic 
Courtès
 
 
-Porting Guix to GNU/Hurd
+Porting Guix to GNU/Hurd
 
 
   GNU Guix currently supports building packages for GNU/Linux only.  The
@@ -704,7 +726,10 @@ implemented by the Unix kernel or similar kernels (such as 
Linux).
 
 Please see
   this separate
-  page for our project ideas, as well as -
+  page for our project ideas, as well as
+  on this page glibc: Implement
+  Missing Interfaces for GNU Hurd and Porting Guix to
+  GNU/Hurd, and also
   our student
   application form.
 


Grüße,
 Thomas


pgp04Q5m99kit.pgp
Description: PGP signature

Re: Google Summer of Code projects for the GNU C Library.

[Thomas Schwinge]

Hi!

On Wed, 19 Feb 2014 19:14:45 -0500, "Carlos O'Donell"  wrote:
> The GNU Project is participating in GSoC 2014 and have asked
> individual GNU projects to nominate their own GSoC projects
> under their umbrella.
> 
> We have proposed an initial three projects for the GNU C Library
> and you can see them here:
> http://www.gnu.org/software/soc-projects/ideas-2014.html
> 
> At present I'm a mentor for glibc and Joseph Myers is a backup
> mentor. However we expect all participation to happen on libc-alpha
> and libc-help and that the community will assist in teaching
> the students how challenging/rewarding it is to work on system
> libraries.
> 
> If anyone has any more project ideas they think a student can
> work on please suggest them here. Keep in mind that the idea
> has to be simple enough for a student to implement in a very
> limited time.
> 
> We might not propose any more, but any ideas we come up with
> I'll put into a GSoC project page and we can draw from there
> next year instead of scrambling like I did today :-)

I have just added »Implement Missing Interfaces for GNU Hurd«,
:

| == Implement Missing Interfaces for GNU Hurd ==
| 
| In glibc's Linux kernel port, most simple POSIX interfaces are in fact just 
forwarded to (implemented by) Linux kernel system calls.
| In contrast, in the [[http://www.gnu.org/software/hurd/glibc.html|GNU Hurd 
port]], the POSIX (and other) interfaces are actually implemented in glibc on 
top of the [[http://www.gnu.org/software/hurd/hurd/rpc.html|Hurd RPC 
protocols]].
| A few examples:
| 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/getuid.c|getuid]],
| 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c|open]],
| 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/rmdir.c|rmdir]],
| 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/setresuid.c|setresuid]],
| 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/socketpair.c|socketpair]].
| 
| When new interfaces are added to glibc (new editions of POSIX and similar 
standards, support for new editions of C/C++ standards, new GNU-specific 
extensions), generally 
[[https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/execve.c|ENOSYS 
stubs]] are added, which are then used as long as there is no real 
implementation, and often these real implementations are only done for the 
Linux kernel port, but not GNU Hurd.
| (This is because most of the contributors are primarily interested in using 
glibc on Linux-based systems.)
| Also, there is quite a backlog of 
[[http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing|missing 
implementations]] for GNU Hurd.
| 
| In coordination with the [[mailto:bug-hurd@gnu.org|GNU Hurd developers]], 
you'd work on implementing such missing interfaces.

Please review/edit/amend/polish this (please shout if you need to be
added to ), and then I'll
soon ask José to also include it on
 as well as put
it on/link to it from
.


Grüße,
 Thomas


pgp5z2HDqZin0.pgp
Description: PGP signature

Google Summer of Code

[Samuel Thibault]

Hello,

This year again, Debian and GNU plan to participate to the Google Summer
of Code.  We should thus update our project proposals on the wiki!

Samuel

Re: Clean up Mach Google Summer Of Code

[Thomas Schwinge]

Hi Josh!

On Thu, 18 Apr 2013 01:18:15 +0200, Samuel Thibault  
wrote:
> Joshua Branson, le Mon 15 Apr 2013 22:49:22 -0400, a écrit :
> > Should I be focused only on fixing compiler
> > warnings, unneeded variables, removing or modify strange code?
> 
> As the subject says, it's actually quite open, so it is not necessarily
> focused.  But you can try to focus on these for a start, and see what
> else comes through this.
> 
> > There are numerous errors I could start to fix, but I do not want to
> > dive in with no sense of direction.
> 
> Well, you'll have to dive someday :) But it can be better to ask
> advice about what could be easiest to begin with.
> 
> For instance "implicit declaration of function", "format ‘%lu’
> expects argument of type..." are easy to start with.

Indeed for an project as open as this, we can't expect you to come up
with a definitive list of items you're to complete, and the time needed
for doing that.  I think it should be enough if you identify some
specific items that can be worked on (for example, certain classes of
compiler warnings, identifying and ripping out unused functionality, make
the code "more readable").

> > Any ideas where or how I can start
> > cleaning of GNU mach? Or perhaps
> > I should ask, where I should look to find an answer.
> 
> You can come on the #hurd IRC channel, in the freenode network, and ping
> people there (make sure to wait for them to wake up, we are not 24/24 in
> front of our IRC client).

Well, you can easily start by sending a patch to fix one specific
compiler warning.


Don't forget to prepare your student application form,
,
and send it to Google site, in time before this Friday.


Grüße,
 Thomas


pgpmkrdCZT_3E.pgp
Description: PGP signature

Google Summer of Code 2013 (was: Project idea link on the wiki)

[Thomas Schwinge]

Hi!

On Tue, 26 Mar 2013 15:53:01 +0100, I wrote:
> On Tue, 26 Mar 2013 14:33:58 +0100, Samuel Thibault  
> wrote:
> > Richard Braun, le Tue 26 Mar 2013 14:02:32 +0100, a écrit :
> > > The current path to reach the project ideas page on the wiki is through
> > > the Contributing page, and then the project ideas link inside the first
> > > block. I think we should improve that and do something similar to what
> > > is done for the open issues : create a link in the side menu, right next
> > > to open issues. I believe it's even more important now that the GSoC is
> > > about to start.
> > 
> > Agreed.
> 
> Yep, as soon as the GSoC is actually running and we have polished our
> project ideas page some more, I'll do as I have done every year; see
> commit be030843d9bea240006e8dbdc423e38fbf4039f1, for example.

Now done in commit a2cd1c245297f5f4f64dd77b5bbaee4f22353ee7,
<http://www.gnu.org/software/hurd/news/2013-04-23.html>:

| The Google Summer of Code 2013 is on! If you're a student, consider
| applying for a GNU Hurd project -- details to be found on our GSoC
| page, <http://www.gnu.org/software/hurd/community/gsoc.html>.

Also, one Debian GNU/Hurd task, »Debian GNU/Hurd Debianish
initialization«, is listed on
<http://wiki.debian.org/SummerOfCode2013/Projects#Debian_GNU.2FHurd_Debianish_initialization>.


Please spread the word; I already have done so on Google+:
<https://plus.google.com/114942488385711891227/posts/9SsfDPi3CBh>.


Grüße,
 Thomas


pgpeczCEL8bTC.pgp
Description: PGP signature

Re: Clean up Mach Google Summer Of Code

[Samuel Thibault]

Hello,

Joshua Branson, le Mon 15 Apr 2013 22:49:22 -0400, a écrit :
> Should I be focused only on fixing compiler
> warnings, unneeded variables, removing or modify strange code?

As the subject says, it's actually quite open, so it is not necessarily
focused.  But you can try to focus on these for a start, and see what
else comes through this.

> There are numerous errors I could start to fix, but I do not want to
> dive in with no sense of direction.

Well, you'll have to dive someday :) But it can be better to ask
advice about what could be easiest to begin with.

For instance "implicit declaration of function", "format ‘%lu’
expects argument of type..." are easy to start with.

> Any ideas where or how I can start
> cleaning of GNU mach? Or perhaps
> I should ask, where I should look to find an answer.

You can come on the #hurd IRC channel, in the freenode network, and ping
people there (make sure to wait for them to wake up, we are not 24/24 in
front of our IRC client).

Samuel

Re: Clean up Mach Google Summer Of Code

[Richard Braun]

On Mon, Apr 15, 2013 at 10:49:22PM -0400, Joshua Branson wrote:
> to learn much more before this summer. I've attached a preliminary
> application, but I do not have a schedule for this potential summer
> project yet.

Just one note about your application: the main point of the GSoC being
paid is to free the student from any other time consuming involvment
during the summer. While I understand it can be difficult to plan ahead
without being certain to be selected, it's also a strong hint for us
that the student is more likely to succeed than another who will also be
busy elsewhere.

-- 
Richard Braun

Re: Google summer of code 2013

[Giuseppe Scrivano]

Thomas Schwinge  writes:

> I can send patches for the following if you prefer, but it's just
> copy'n'paste.  For GNU Hurd, please copy the entry from
> ; we're
> working on updating or list of project ideas.  Any reason not to add a
> reference to ideas-2012.html to the list of previous years on top of
> ?

No need, the copy'n'paste was easy :-)  I have added a section for Hurd.

The ideas page for the GSoC 2012 should be also listed now.

Cheers,
Giuseppe

Re: Google summer of code 2013

[Thomas Schwinge]

Hi!

On Wed, 06 Mar 2013 21:42:44 +0100, jema...@gnu.org (Jose E. Marchesi) wrote:
> As it is usual, this year GNU will be applying to become a Google Summer
> of Code [0] organization.  Provided we get selected I will be the org
> admin and Giuseppe Scrivano will volunteer as the co-admin.

> - If you are a GNU package developer, have an idea for a Summer of Code
>   project for your own package, and can mentor it yourself, please email
>   the idea at summer-of-c...@gnu.org and one of the administrators will
>   add it. (Simple HTML fragment in plain text preferred.) Please also
>   recruit a backup mentor and tell us who that will be. Make sure that
>   the description of your idea contains enough information (perhaps in
>   the form of pointers to other information or mailing lists) for
>   students to research the feasibility of them implementing your
>   idea. More info.

> [1] http://www.gnu.org/software/soc-projects/ideas.html

I can send patches for the following if you prefer, but it's just
copy'n'paste.  For GNU Hurd, please copy the entry from
<http://www.gnu.org/software/soc-projects/ideas-2012.html#hurd>; we're
working on updating or list of project ideas.  Any reason not to add a
reference to ideas-2012.html to the list of previous years on top of
<http://www.gnu.org/software/soc-projects/ideas-2013.html>?


Grüße,
 Thomas


pgpoZ5zN7kAir.pgp
Description: PGP signature

RE: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Thomas Schwinge]

Hi!

On Fri, 15 Feb 2013 17:07:39 +1300, "Nolan Tunnicliffe"  
wrote:
> I don't mind where a Rust port to Hurd is discussed. To get some of 
> the technical answers regarding Rust though you may need to ask
> on reddit.com or maybe the rust-...@mozilla.org. Although I will
>  research what I can. I'm not a language developer myself.
> 
> I'm not a student so I can't participate in the GSOC myself.

Oh, then I had totally misunderstood that part -- I though it was you
suggesting a GSoC project you want to work on yourself, not you
suggesting a GSoC project for someone else to work on.  :-)

> As I
> understand it anyone can suggest a project though. I am willing
> to begin with investigating a port of Rust, with your help.

Of course, the project itself is not tied to GSoC, so, yes, you're
welcome to continue working on that.  Likewise, you're of course welcome
to continue "lobbying" on the Rust side in case a student (or Rust
developer, of course) is interested in this project, too.

(As you surely have noticed/guessed by my more-or-less absence of a few
weeks), I won't be able to spend a lot of time working on this myself,
but I as well as others from our small team will always try to provide
answers to specific questions.


Grüße,
 Thomas


pgpdbhlsP30bp.pgp
Description: PGP signature

Re: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Samuel Thibault]

Nolan Tunnicliffe, le Fri 15 Feb 2013 17:07:39 +1300, a écrit :
> >Samuel Thibault wrote
> >I however have to say you probably underestimate the amount of work  
> >needed to write a driver.  The language can help in some way, but not 
> >very much.  The main part of difficulty is to manage to understand how 
> >the device really works, and devise something that works with it. We 
> >don't really want to spend time on this, and rather use a maintained 
> >layer like DDE.
> If you will be able to use Linux drivers, perfect. I was under the impression
>  that rewrites were required.

Nope, we take the drivers source code as it is.

Samuel

RE: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Nolan Tunnicliffe]

I don't mind where a Rust port to Hurd is discussed. To get some of 
the technical answers regarding Rust though you may need to ask
on reddit.com or maybe the rust-...@mozilla.org. Although I will
 research what I can. I'm not a language developer myself.

I'm not a student so I can't participate in the GSOC myself. As I
understand it anyone can suggest a project though. I am willing
to begin with investigating a port of Rust, with your help.

>Please verify (or ask us to help looking at the Rust sources if you're
>unsure): it does have a functional x86 (that is, 32-bit) GNU/Linux 
>port, which generally is  implemented on top of the usual Unix/POSIX as 
>well as glibc APIs (»#define  _GNU_SOURCE«), and makes little or no use 
>of direct Linux kernel syscalls (such as futex,  for example).
I will investigate further. I have to reinstall Linux and get the Rust source
 as I can't find a way with github web service  to searching inside source.

>> no null or dangling pointers, no buffer overflows
>How is this implemented?  Internal reference counting, or garbage 
>collection?  If the latter, which engine?
"The safe pointer types are @T, for managed boxes allocated on the
 local heap, ~T, for uniquely-owned boxes allocated on the exchange
 heap, and &T, for borrowed pointers, which may point to any memory,
 and whose lifetimes are governed by the call stack.

Currently, the Rust compiler generates code to reclaim managed boxes
 through reference counting and a cycle collector, but we will switch to 
a tracing garbage collector eventually."
See below for link to details about future garbage collector design.

>> lightweight tasks with message passing, no shared memory
>How implemented?  Standard pthread interfaces or some internal thing (using 
>which kernel interface)?
"bblum at andrew.cmu.edu  This summer I worked on Rust's
 concurrency/parallelism libraries  (The underlying concurrency
 primitives - semaphores, mutexes, rwlocks, condvars - can also
 be used directly, in std::sync, in case you have some state external
 to rust that needs to be protected, such as when linking to a C library
 or using the filesystem. These should be preferred over the pthread
 ones because these are rust-scheduler- aware; i.e., other rust tasks
 can be scheduled on your CPU while you are blocked on one of these.)"
Ben probably knows the answer.

>> Exception handling
>> unrecoverable unwinding with task isolation
>Requiring run-time/operating system support, or based on standard DWARF?
To be investigated.

>Aha, garbage collection.  How implemented/which engine?  (Boehm?)
https://github.com/elliottslaughter/rust-gc-talk

>More specifically, how do you get from Rust source code to executing machine 
>code?
...

>What is your expertise as a Rust programmer (using Rust), Rust 
>developer (developing Rust  itself), and programming language 
>implementation generally, focussing not on the computer  science part of it 
>;-) but on the actual implementation, host system interfaces, and so on?
I'm a new Rust programmer/developer wanting to write OS components
 in Rust and contribute to porting Rust to Hurd and extending Hurd.

See my contribution regarding writing a virtual file system translator
and implementing a missing Rust library via a layer at the same time.

>In the following the terminology is sometimes unclear (maybe this simply is 
>"new ground"
> for you?), for example, often when you say »kernel« that should -- in 
>our terminology -- be  »operating system«; by kernel we normally 
>understand the GNU Mach microkernel, the  base of the operating system.  
>What experience do you have with operating system  implementation?
I would have liked more time to get up to speed with Hurd but the subject
 of GSOC came up on both this and the Rust forum and I wanted to post
while it was relevant. You have to remember that most of that post was
 meant for the Rust list.

I am reasonably new to well layered modern kernels and the concept of
 microkernels. It's mainly a terminology issue. I understand, at least what
 I said in my post, I just can't articulate it using the correct terminology
currently. See what I said above regarding to being forced into posting
 prematurely posting as GSOC was in discussion.

>Implementing device drivers in Rust is yet another project.  Generally 
>(due to the complexity  and sheer number of drivers), the tendency has 
>been in "use" another operating system's  drivers (such as Linux') by 
>implementing some sort of glue-code to embed and run them.
> But of course, once the RPC interfaces are available in the Rust 
>language/libraries, it would  be possible to implement device drivers, too.

I had assumed that because a layer for network card was required that
 each category of driver would need layering and so suggesting there
 would be a demand for new drivers to be written in, potentially a new
 language. That would offer vast driver support If Linux drivers can be used.



>> Even if having the maj

Re: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Samuel Thibault]

Hello,

Well, porting Rust to GNU/Hurd definitely can be useful, so your project
is more than welcome in that regard.

I however have to say you probably underestimate the amount of work
needed to write a driver.  The language can help in some way, but not
very much.  The main part of difficulty is to manage to understand how
the device really works, and devise something that works with it. We
don't really want to spend time on this, and rather use a maintained
layer like DDE.

Samuel

Re: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Thomas Schwinge]

Hi!

On Thu, 14 Feb 2013 15:26:46 +1300, "Nolan Tunnicliffe"  
wrote:
> http://www.reddit.com/r/rust/comments/18dfd6/gsoc_2013_started_any_rust_project_ideas/

Thanks for this proposal (the very first we (GNU Hurd) get this year)!
Looks like a good project to me.

As you posted it on , I'll assume you'd like it
discussed there.  I'd also be fine posting/subscribing to a Rust mailing
list.  [Well, in fact I simply cross-posted the email there (and tried
subscribing, which currently doesn't seem to work, though); please keep
everyone in copy.]  Reddit would be an unusual place (for us, at least)
to discuss technical topics.


Many of my following questions may already be answered in the regular
Rust documentation -- which I have not yet had the chance to chase up.
Of course it is fine to simply give pointers that answer my questions.

> Rust is a language sponsored by Mozilla who are using it to write a next
> generation web browser engine. It is low level hardware access capable,
> making it a potential replacement for C and C++ for writing device drivers.

Please verify (or ask us to help looking at the Rust sources if you're
unsure): it does have a functional x86 (that is, 32-bit) GNU/Linux port,
which generally is implemented on top of the usual Unix/POSIX as well as
glibc APIs (»#define _GNU_SOURCE«), and makes little or no use of direct
Linux kernel syscalls (such as futex, for example).

> From http://www.rust-lang.org/ :
> 
> Rust is a curly-brace, block-structured expression language. It visually
> resembles the C language family, but differs significantly in syntactic and
> semantic details. Its design is oriented toward concerns of "programming in
> the large", that is, of creating and maintaining boundaries - both abstract
> and operational - that preserve large-system integrity, availability and
> concurrency. 
> 
> It supports a mixture of imperative procedural, concurrent actor,
> object-oriented and pure functional styles. Rust also supports generic
> programming and metaprogramming, in both static and dynamic styles. 

Look, it has *all of it*!  ;-)

> Memory safety
> 
> no null or dangling pointers, no buffer overflows

How is this implemented?  Internal reference counting, or garbage
collection?  If the latter, which engine?

> Concurrency
> 
> lightweight tasks with message passing, no shared memory

How implemented?  Standard pthread interfaces or some internal thing
(using which kernel interface)?

> Exception handling
> 
> unrecoverable unwinding with task isolation

Requiring run-time/operating system support, or based on standard DWARF?

> Memory model
> 
> optional task-local GC, safe pointer types with region analysis

Aha, garbage collection.  How implemented/which engine?  (Boehm?)

> Compilation model
> 
> ahead-of-time, C/C++ compatible

More specifically, how do you get from Rust source code to executing
machine code?


What is your expertise as a Rust programmer (using Rust), Rust developer
(developing Rust itself), and programming language implementation
generally, focussing not on the copmuter science part of it ;-) but on
the actual implementation, host system interfaces, and so on?


In the following the terminology is sometimes unclear (maybe this simply
is "new ground" for you?), for example, often when you say »kernel« that
should -- in our terminology -- be »operating system«; by kernel we
normally understand the GNU Mach microkernel, the base of the operating
system.  What experience do you have with operating system
implementation?

(These questions, by the way, are just so that we get a feeling about
what we can roughly expect you to know, and what we first have to teach
you -- but no problem with that, of course!)

> For the Google Summer of Code 2013, Port the Mozilla Rust
> http://www.rust-lang.org/ programming language to GNU Hurd, Mach based
> operating system microkernel. GNU Hurd microkernel allows any language that
> can RPC Remote Procedure Call http://www.gnu.org/software/hurd/hurd/rpc.html
> to write kernel 'servers' ie. components of the kernel that in Mach's case
> run in User mode as opposed to Kernel mode. Allowing an existing modern
> functioning kernel to be written, extended and potentially parts rewritten
> in Rust. Kernel writers would use a modern low level capable language, Rust,
> to extend a functioning kernel and components in a language that was
> designed to preserve large-system integrity, availability and concurrency,
> some of the same goals of GNU Hurd project itself.

This in fact is a separate project, which first requires a general port
of the Rust programming environment to GNU/Hurd, which I cannot judge yet
how difficult it will be.  But of course it (enabling Hurd interfaces
(RPCs) in Rust) is a very desirable follow-on project!

Re: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Thomas Schwinge]

Hi!

On Thu, 14 Feb 2013 15:26:46 +1300, "Nolan Tunnicliffe"  
wrote:
> http://www.reddit.com/r/rust/comments/18dfd6/gsoc_2013_started_any_rust_project_ideas/

Thanks for this proposal (the very first we (GNU Hurd) get this year)!
Looks like a good project to me.

As you posted it on , I'll assume you'd like it
discussed there.  I'd also be fine posting/subscribing to a Rust mailing
list.  [Well, in fact I simply cross-posted the email there (and tried
subscribing, which currently doesn't seem to work, though); please keep
everyone in copy.]  Reddit would be an unusual place (for us, at least)
to discuss technical topics.


Many of my following questions may already be answered in the regular
Rust documentation -- which I have not yet had the chance to chase up.
Of course it is fine to simply give pointers that answer my questions.

> Rust is a language sponsored by Mozilla who are using it to write a next
> generation web browser engine. It is low level hardware access capable,
> making it a potential replacement for C and C++ for writing device drivers.

Please verify (or ask us to help looking at the Rust sources if you're
unsure): it does have a functional x86 (that is, 32-bit) GNU/Linux port,
which generally is implemented on top of the usual Unix/POSIX as well as
glibc APIs (»#define _GNU_SOURCE«), and makes little or no use of direct
Linux kernel syscalls (such as futex, for example).

> From http://www.rust-lang.org/ :
> 
> Rust is a curly-brace, block-structured expression language. It visually
> resembles the C language family, but differs significantly in syntactic and
> semantic details. Its design is oriented toward concerns of "programming in
> the large", that is, of creating and maintaining boundaries - both abstract
> and operational - that preserve large-system integrity, availability and
> concurrency. 
> 
> It supports a mixture of imperative procedural, concurrent actor,
> object-oriented and pure functional styles. Rust also supports generic
> programming and metaprogramming, in both static and dynamic styles. 

Look, it has *all of it*!  ;-)

> Memory safety
> 
> no null or dangling pointers, no buffer overflows

How is this implemented?  Internal reference counting, or garbage
collection?  If the latter, which engine?

> Concurrency
> 
> lightweight tasks with message passing, no shared memory

How implemented?  Standard pthread interfaces or some internal thing
(using which kernel interface)?

> Exception handling
> 
> unrecoverable unwinding with task isolation

Requiring run-time/operating system support, or based on standard DWARF?

> Memory model
> 
> optional task-local GC, safe pointer types with region analysis

Aha, garbage collection.  How implemented/which engine?  (Boehm?)

> Compilation model
> 
> ahead-of-time, C/C++ compatible

More specifically, how do you get from Rust source code to executing
machine code?


What is your expertise as a Rust programmer (using Rust), Rust developer
(developing Rust itself), and programming language implementation
generally, focussing not on the copmuter science part of it ;-) but on
the actual implementation, host system interfaces, and so on?


In the following the terminology is sometimes unclear (maybe this simply
is "new ground" for you?), for example, often when you say »kernel« that
should -- in our terminology -- be »operating system«; by kernel we
normally understand the GNU Mach microkernel, the base of the operating
system.  What experience do you have with operating system
implementation?

(These questions, by the way, are just so that we get a feeling about
what we can roughly expect you to know, and what we first have to teach
you -- but no problem with that, of course!)

> For the Google Summer of Code 2013, Port the Mozilla Rust
> http://www.rust-lang.org/ programming language to GNU Hurd, Mach based
> operating system microkernel. GNU Hurd microkernel allows any language that
> can RPC Remote Procedure Call http://www.gnu.org/software/hurd/hurd/rpc.html
> to write kernel 'servers' ie. components of the kernel that in Mach's case
> run in User mode as opposed to Kernel mode. Allowing an existing modern
> functioning kernel to be written, extended and potentially parts rewritten
> in Rust. Kernel writers would use a modern low level capable language, Rust,
> to extend a functioning kernel and components in a language that was
> designed to preserve large-system integrity, availability and concurrency,
> some of the same goals of GNU Hurd project itself.

This in fact is a separate project, which first requires a general port
of the Rust programming environment to GNU/Hurd, which I cannot judge yet
how difficult it will be.  But of course it (enabling Hurd interfaces
(RPCs) in Rust) is a very desirable follow-on project!

[Google Summer of Code 2013] - Mozilla Rust language bindings

[Nolan Tunnicliffe]

The project suggestion below was written for Rust programmers, and would be
common knowledge for GNU Hurd developers, due to the subject of GSOC 2013
coming up on the Rust reddit.com forum. If interested in this could you
please go to
http://www.reddit.com/r/rust/comments/18dfd6/gsoc_2013_started_any_rust_proj
ect_ideas/ and click the arrow to show your support for this project.

 

Rust is a language sponsored by Mozilla who are using it to write a next
generation web browser engine. It is low level hardware access capable,
making it a potential replacement for C and C++ for writing device drivers.

 

>From http://www.rust-lang.org/ :

Rust is a curly-brace, block-structured expression language. It visually
resembles the C language family, but differs significantly in syntactic and
semantic details. Its design is oriented toward concerns of "programming in
the large", that is, of creating and maintaining boundaries - both abstract
and operational - that preserve large-system integrity, availability and
concurrency. 

It supports a mixture of imperative procedural, concurrent actor,
object-oriented and pure functional styles. Rust also supports generic
programming and metaprogramming, in both static and dynamic styles. 


Type system

static, nominal, linear, algebraic, locally inferred


Memory safety

no null or dangling pointers, no buffer overflows


Concurrency

lightweight tasks with message passing, no shared memory


Generics

type parameterization with type classes


Exception handling

unrecoverable unwinding with task isolation


Memory model

optional task-local GC, safe pointer types with region analysis


Compilation model

ahead-of-time, C/C++ compatible


License

dual MIT / Apache 2

 

For the Google Summer of Code 2013, Port the Mozilla Rust
http://www.rust-lang.org/ programming language to GNU Hurd, Mach based
operating system microkernel. GNU Hurd microkernel allows any language that
can RPC Remote Procedure Call http://www.gnu.org/software/hurd/hurd/rpc.html
to write kernel 'servers' ie. components of the kernel that in Mach's case
run in User mode as opposed to Kernel mode. Allowing an existing modern
functioning kernel to be written, extended and potentially parts rewritten
in Rust. Kernel writers would use a modern low level capable language, Rust,
to extend a functioning kernel and components in a language that was
designed to preserve large-system integrity, availability and concurrency,
some of the same goals of GNU Hurd project itself.

 

GNU Hurd allows runtime installation of user mode, and most are, kernel
components that do not require root access or a reboot to install and if
they crash do not bring the whole kernel down. Unlike most UNIX's, GNU Hurd
is designed to be modified and extended through system hooks. The kernel can
be developed and progress at a potentially different pace compared to Linux.
A lot of functionality is implemented as file system interfaces
'translators' which may be another way of providing further features to Rust
without reprioritizing language features such as httpfs virtual filesystem
and netio http://www.gnu.org/software/hurd/hurd/translator.html . Perhaps
Hurd translators or Rust library features can be written with a layer such
that you can add the feature to a GNU Hurd virtual file system 'translator'
AND Rust library with a single implementation. Work on either is work on
both.

 

Potentially this could mean that one missing aspect of GNU Hurd, drivers,
could be written in Rust with the advantage that they are written in a
modern language, for making the sacrifice of having to rewrite drivers to
work on this kernel as opposed to sticking with existing drivers written in
'C' and Linux. Turning the disadvantage in the lack of drivers currently
written for Hurd into an advantage that they could now be written in a new
language, Rust. Making the assumption that hardware device drivers can
currently be written for GNU Hurd in any language that can RPC and has low
level hardware access capability. I believe the project to make userspace
drivers exists if not yet fully realized.

 

Even if having the majority of drivers written in Rust is optimistic the
above two paragraphs still suggest the advantages of Rust language bindings
for GNU Hurd such as being able to write a currently functioning microkernel
in the Rust language with all the benefits that implies for both Rust
programmers and the GNU Hurd microkernel.

 

78% of the Debian archive builds out of the tree on Debian GNU/Hurd.

 

GNU/Hurd Plans For A Future With USB, SATA, 64-Bit
http://www.phoronix.com/scan.php?page=news_item
<http://www.phoronix.com/scan.php?page=news_item&px=MTI5ODM> &px=MTI5ODM

http://www.gnu.org/software/hurd/hurd.html

 

 

Modern kernel writing, in a modern language.

 

[Carol Smith] [GSoC Mentors Announce] Google Summer of Code 2013

[Thomas Schwinge]

Hi!

There will be a Google Summer of Code 2013, see below.  Assuming GNU is
again going to apply and accepted as a mentoring organization -- if we're
interested, we can also already begin thinking about projects to propose.
<http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/> has
the current list; to be updated.  Speak up (or directly edit the pages)
if you have any suggestions!

| From: Carol Smith 
| Date: Mon, 11 Feb 2013 11:02:32 -0800
| Message-ID: 

| Subject: [GSoC Mentors Announce] Google Summer of Code 2013
| To: gsoc-mentors-annou...@googlegroups.com
| Reply-To: gsoc-mentors-announce+own...@googlegroups.com
| 
| Hi GSoC mentors and org admins,
| 
| We've announced that we're doing Google Summer of Code 2013 [1]. Yay!
| 
| If you would like to help spread the word about GSoC, we have presentations
| [2], logos [3], and flyers [4] for you to use. Please host meetups, tell
| your friends and colleagues about the program, go to conferences, talk to
| people about the program, and just generally do all the awesome
| word-of-mouth stuff you do every year to promote the program.
| 
| The GSoC calendar, FAQ, and events timeline have all been updated with this
| year's important dates, so please refer to those for the milestones for
| this year's program. NB: the normal timeline for the program has been
| modified for this year. You'll probably want to examine the dates closely
| to make sure you know when important things are happening.
| 
| Please consider translating the presentations and/or flyers into your
| native language and submitting them directly to me to post on the wiki.
| Localization for our material is integral to reaching the widest possible
| audience around the world. If you decide to translate a flyer, please fill
| out our form to request a thank you gift for your effort. [5]
| 
| If you decide to host a meetup, please email me to let me know the date,
| time, and location so I can put it on the GSoC calendar. Also, remember to
| take pictures at your meetup and write up a blog post for our blog using
| our provided template for formatting [6]. If you need promotional items for
| your attendees, please fill out our form [7] to request some; we're happy
| to send some along. We can provide up to about 25 pens, notebooks, or
| stickers and/or a few t-shirts. Please keep in mind, though, that shipping
| restrictions and timeline vary country-to-country; request items early to
| make sure they get there on time! If you have questions about hosting
| meetups, please see the section in our FAQ [8].
| 
| Please also consider applying to participate as an organization again this
| year or maybe joining as a mentor for your favorite organization if they
| are selected this year.
| 
| We rely on you for your help for the success of this program, so thank you
| in advance for all the work you do!
| 
| [1] -
| 
http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html
| [2] -
| http://code.google.com/p/google-summer-of-code/wiki/ProgramPresentations
| [3] - http://code.google.com/p/google-summer-of-code/wiki/GsocLogos
| [4] - http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers
| [5] - http://goo.gl/gEHDO
| [6] - http://goo.gl/wbZrt
| [7] - http://goo.gl/0BsR8
| [8] - http://goo.gl/2NGfp
| 
| Cheers,
| Carol


Grüße,
 Thomas


pgpNl34dRDwOm.pgp
Description: PGP signature

Google Summer of Code 2012

[Thomas Schwinge]

Hi!

The Google Summer of Code 2012 is on!  If you're a student, consider
applying for a GNU Hurd project -- details to be found on
<http://www.gnu.org/software/hurd/community/gsoc.html>.


Grüße,
 Thomas


pgpex7ds1kzus.pgp
Description: PGP signature

Re: Savannah Hurd group / Google Summer of Code 2010

[Thomas Schwinge]

Hello!

On Wed, Apr 28, 2010 at 01:15:42PM +0200, I wrote:
>   * karim.allah / Karim Allah Ahmed  -- will
> be working as a Google Summer of Code 2010 student on ``Hurd: Fix
> Compatibility Problems Exposed by Testsuites''
> 
> <http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396>.
> 
>   * pochu / Emilio Pozuelo Monfort  -- will be working
> as a Google Summer of Code 2010 student on ``Tuning the VM Subsystem
> in GNU/Hurd ''
> 
> <http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587>.

As Emilio rightfully mentioned, I put the right names to the wrong tasks
(or vice versa).  Karim is working on the Mach virtual memory system, and
Emilio on categorizing / documenting / fixing testsuite failures.  Sorry
for that.


Regards,
 Thomas


signature.asc
Description: Digital signature

Savannah Hurd group / Google Summer of Code 2010

[Thomas Schwinge]

Hello!

The Google Summer of Code 2010 is on.  Please welcome our new folks!


I have added a few people to the Savannah Hurd group:

  * karim.allah / Karim Allah Ahmed  -- will
be working as a Google Summer of Code 2010 student on ``Hurd: Fix
Compatibility Problems Exposed by Testsuites''

<http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396>.

  * pochu / Emilio Pozuelo Monfort  -- will be working
as a Google Summer of Code 2010 student on ``Tuning the VM Subsystem
in GNU/Hurd ''

<http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587>.

  * k0ro / Sergio López  -- will be mentoring
Karim.

hammy / Carl Fredrik Hammar  will be mentoring
Emilio, but already has an account from his earlier GSoC work.


I'm planning on adding Olaf Buddenhagen  too,
once he has created an account on Savannah.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Hurd vs. Google Summer of Code 2010

[olafBuddenhagen]

Hi,

On Fri, Mar 12, 2010 at 07:44:56PM +0100, Thomas Schwinge wrote:
> > On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote:

> > > I did some further changes: the guys evaluating all these many
> > > organizations' applications very likely don't want to read --
> > > inside the oranization's description -- what the GPL is, for
> > > example.  Also I did more tidy up, to make the text shorter, while
> > > keeping (most of) the content.

I ultimately decided to rewrite it almost completely, and dropped the
politics too... But the new version is not really shorter than the
original. Hope it's more expressive though...

> Yep, it's always difficult to be concise and easily readable at the
> same time.

Nah, the readability is not the major problem... Saying all I want to
say is :-)

> > > Unless someone objects, I'll add my link ID to the page.
[...]
> Done.  I had to do some searches to find it; it's `tschwinge' -- who
> would have guessed that...

Actually, it's sufficient to go to the GSoC page, log in with your
Google account, and go to "Edit Profile"... :-)

-antrik-

Re: Hurd vs. Google Summer of Code 2010

[Thomas Schwinge]

Hello!

On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net wrote:
> On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote:
> > On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net
> > wrote:
> > >http://www.bddebian.com/~hurd-web/community/gsoc/
> > 
> > I did some enhancements (I hope) and pushed them.
> 
> Thanks for both the content enhancements, [...]

As Fredrik said.  ;-)


> > > Please take a look at the organisation application form,
> > > 
> > >
> > > http://www.bddebian.com/~hurd-web/community/gsoc/organization_application/
> > 
> > I did some further changes: the guys evaluating all these many
> > organizations' applications very likely don't want to read -- inside
> > the oranization's description -- what the GPL is, for example.  Also I
> > did more tidy up, to make the text shorter, while keeping (most of)
> > the content.
> 
> Note that this text is *not* only for the sake of the Google reviewers;
> it is also the initial text to show up on the organisation page if we
> get accepted.

Aha, I didn't know that!  Nevertheless, I wouldn't see a problem -- I'd
even do it that way -- to first make the text fit for the organization
applications' reviewers (as concise as possible, for example), and then
later make it fit for the students (more detailed, for example).  That
way, both different parties can get the biggest use out of the text.

> While the Google folks hopefully know by now what free software is about
> (from our previous applications if nothing else...), this is definitely
> not true for a major portion of the students who will be reading this
> text.

True.

> Having said that, I *did* consider making it shorter -- but in the end,
> I couldn't decide which parts to strike out :-)

Yep, it's always difficult to be concise and easily readable at the same
time.


> > I pushed these changes to the flubber repository,
> > tschwinge/gsoc branch.  I plan to merge that into master in a day or two,
> > unless someone (Olaf) objects.

By now, you picked some of my other improvements (or: changes) ;-), and
dropped others; that's fine.

> As time is pressing, I guess that's fine in this case; but in general,
> "a day or two" is too short notice for me... I often don't read mails
> for several days in a row.

OK.


> > > Also, we need a backup organisation administrator. Any takers?
> > 
> > Me.  Unless someone objects, I'll add my link ID to the page.
> 
> Please do :-)

Done.  I had to do some searches to find it; it's `tschwinge' -- who
would have guessed that...


> I was somewhat unsure, as you were a bit silent over the past couple of
> days -- I thought that if you are so busy, perhaps it would be better
> for someone else to take over. But if you feel up to it, all the better
> :-)

Yes, yes, busy, busy, busy.  But there's progress: the sun tracing
controller project is mostly finished: the prototype is to be installed
next week.  After that, I'll have more time again.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Hurd vs. Google Summer of Code 2010

[Carl Fredrik Hammar]

Hi,

On Thu, Mar 11, 2010 at 03:33:56PM +0100, olafbuddenha...@gmx.net wrote:
> On Thu, Mar 11, 2010 at 01:18:05PM +0100, Carl Fredrik Hammar wrote:
> > On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net
> > wrote:
> > 
> > > Thanks for both the content enhancements, and for catching all those
> > > typos... (And the rather embarrassing non-typos.)
> > 
> > The typos outside of the organization application form was all me.
> 
> Oh, sorry... Didn't spot this among all those other commits from Thomas.
> So thanks and blame for these go to you of course -- please make good
> use of both ;-)

I'll try to be a bit more conservative next time.  :-)

Regards,
  Fredrik

Re: Hurd vs. Google Summer of Code 2010

[olafBuddenhagen]

Hi,

On Thu, Mar 11, 2010 at 01:18:05PM +0100, Carl Fredrik Hammar wrote:
> On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net
> wrote:

> > Thanks for both the content enhancements, and for catching all those
> > typos... (And the rather embarrassing non-typos.)
> 
> The typos outside of the organization application form was all me.

Oh, sorry... Didn't spot this among all those other commits from Thomas.
So thanks and blame for these go to you of course -- please make good
use of both ;-)

> > I do have a couple of quibbles regarding some of the spelling
> > changes though:
> > 
> > - "microkernel" is actually the standard spelling; and while
> > "micro-kernel" is sometimes used too, "micro kernel" is very odd. I
> > actively object to this change.
> > 
> > BTW, "userspace" is also pretty common, though "user space" is fine
> > too. And I don't think "harddisk" is really wrong either, even if
> > "hard disk" seems to be more common.
> 
> I just did a check on what seemed to be the most standard version on
> google and wikipedia and went with that.

I actually did the same, just to be sure :-) Though "userspace" vs.
"user space" looked about even...

Anyways, as I said, while I don't think these changes were necessary, I
don't mind them, aside from the microkernel one.

> For some reason I didn't check it for microkernel, so I'll be
> reverting this.  Answering y/n can get mind numbing after a while...

Right... Thanks again for doing it :-)

> > - "optimisation", "specialised", and "behaviour" are just as correct
> > as the other spellings -- they are British English. (Admittedly, I'm
> > not always consistent with BE vs. AE...)
> 
> Yes, misspelling is a misnomer here, but I do think that AE should be
> standard spelling on the website since it is de facto standard for CS
> documentation in general.

Standardise on the illiterate Americans!? ;-)

Probably you are right... I guess I just like being different ;-)

-antrik-

Re: Hurd vs. Google Summer of Code 2010

[Carl Fredrik Hammar]

Hi,

On Thu, Mar 11, 2010 at 05:12:47AM +0100, olafbuddenha...@gmx.net wrote:
> On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote:
> > On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net
> > wrote:
> 
> > > The results of my labour are available from
> > > 
> > >http://www.bddebian.com/~hurd-web/community/gsoc/
> > 
> > I did some enhancements (I hope) and pushed them.
> 
> Thanks for both the content enhancements, and for catching all those
> typos... (And the rather embarrassing non-typos.)

The typos outside of the organization application form was all me.  I just
ran a spell checker on the files, which sometimes does not suggest the
right thing.

> I do have a couple of quibbles regarding some of the spelling changes
> though:
> 
> - "microkernel" is actually the standard spelling; and while
>   "micro-kernel" is sometimes used too, "micro kernel" is very odd. I
>   actively object to this change.
> 
> BTW, "userspace" is also pretty common, though "user space" is fine too.
> And I don't think "harddisk" is really wrong either, even if "hard disk"
> seems to be more common.

I just did a check on what seemed to be the most standard version on
google and wikipedia and went with that.  For some reason I didn't check
it for microkernel, so I'll be reverting this.  Answering y/n can get
mind numbing after a while...

Though in hindsight such changes are a bit silly.

> - "optimisation", "specialised", and "behaviour" are just as correct as
>   the other spellings -- they are British English. (Admittedly, I'm not
>   always consistent with BE vs. AE...)

Yes, misspelling is a misnomer here, but I do think that AE should be
standard spelling on the website since it is de facto standard for CS
documentation in general.  Though I don't feel very strongly about it.

Regards,
  Fredrik

Re: Hurd vs. Google Summer of Code 2010

[olafBuddenhagen]

Hi,

On Wed, Mar 10, 2010 at 02:43:35PM +0100, Thomas Schwinge wrote:
> On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net
> wrote:

> > The results of my labour are available from
> > 
> >http://www.bddebian.com/~hurd-web/community/gsoc/
> 
> I did some enhancements (I hope) and pushed them.

Thanks for both the content enhancements, and for catching all those
typos... (And the rather embarrassing non-typos.)

I do have a couple of quibbles regarding some of the spelling changes
though:

- "microkernel" is actually the standard spelling; and while
  "micro-kernel" is sometimes used too, "micro kernel" is very odd. I
  actively object to this change.

BTW, "userspace" is also pretty common, though "user space" is fine too.
And I don't think "harddisk" is really wrong either, even if "hard disk"
seems to be more common.

- "optimisation", "specialised", and "behaviour" are just as correct as
  the other spellings -- they are British English. (Admittedly, I'm not
  always consistent with BE vs. AE...)

> > Please take a look at the organisation application form,
> > 
> >
> > http://www.bddebian.com/~hurd-web/community/gsoc/organization_application/
> 
> I did some further changes: the guys evaluating all these many
> organizations' applications very likely don't want to read -- inside
> the oranization's description -- what the GPL is, for example.  Also I
> did more tidy up, to make the text shorter, while keeping (most of)
> the content.

Note that this text is *not* only for the sake of the Google reviewers;
it is also the initial text to show up on the organisation page if we
get accepted. While it is still possible to adjust that afterwards, I'm
not conviced it's a good idea to make major changes...

While the Google folks hopefully know by now what free software is about
(from our previous applications if nothing else...), this is definitely
not true for a major portion of the students who will be reading this
text.

Having said that, I *did* consider making it shorter -- but in the end,
I couldn't decide which parts to strike out :-)

The part about freedom etc. is actually required to explain how the Hurd
goals directly follow from the GNU philosophy. While it's certainly
possible to explain the technical benefits without it, I tend to think
that we should try to introduce students interested in the project to
our philosophy as early as possible...

I don't really insist on this though.

As for the other changes, some are probably indeed an improvement; some
others I'm not so sure about... I'll comment on those I have serious
doubts about:

>  * Why is your organization applying to participate in GSoC 2010? What do you 
> hope to gain by participating?
>  
> -The primary goal of course is to find and introduce new long-term 
> contributors
> +The primary goal is to find and introduce new long-term contributors
>  to the project.

Mm... I put the "of course" there, because this is indeed officially the
main purpose of GSoC. I feel that when restating the odvious, we should
make it clear that we are doing that. But perhaps that's just me ;-)

> -Aside from that, it is a way to make progress with tasks that require an 
> amount of
> -focused work, that is hard to do for volunteers working in their spare time
> +We seek to make progress with tasks that require a distinct amount of focused
> +work, which is hard to fulfill by volunteers working in their spare time
>  only.

I agree that this section is quite awkward; but I'm not convinced about
your wording either...

Actually I consider dropping this section alltogether, or trying to
rewrite it. Experience has shown that even if the students are very
good, the work they do during the summer session alone doesn't generally
bring much benefit to the project, unless they stick around after the
summer and follow up on it. Thus I do not generally consider "getting
work done" a goal of our GSoC participation anymore.

It's true though that the mentor-student setup, together with the period
of intense work, *do* help with starting innovative new projects, which
do not generally happen otherwise. (I'm not even sure the "volunteer"
aspect is relevant in this at all.) I do not quite know how to properly
put this into words though :-(

>  In 2008 we participated as an organisation on our own for the first time. 
> This
> -turned out extremely beneficial: With the better visibility, we get a lot
> +turned out extremely beneficial: With the better visibility, we got a lot
>  more applications (more than 20), mostly of good or excellent quality.

Actually there is another mistake in this line: "with" should not be
capitalised :-)

BTW, I'm not entirely happy with this part of the sentence anyways:
while I think "visibility" hits it well, the rest of the wording around
it is a bit strange...

>  While the 2006 student disappeared midway, in all the later years all of our
> -students were successful -- including even one who worked on his project 

Re: Hurd vs. Google Summer of Code 2010

[Thomas Schwinge]

Hello!

On Wed, Mar 10, 2010 at 08:02:30AM +0100, olafbuddenha...@gmx.net wrote:
> On Tue, Mar 09, 2010 at 04:08:27PM +0100, Arne Babenhauserheide wrote:
> The results of my labour are available from
> 
>http://www.bddebian.com/~hurd-web/community/gsoc/

I did some enhancements (I hope) and pushed them.

> Please take a look at the organisation application form,
> 
>http://www.bddebian.com/~hurd-web/community/gsoc/organization_application/

I did some further changes: the guys evaluating all these many
organizations' applications very likely don't want to read -- inside the
oranization's description -- what the GPL is, for example.  Also I did
more tidy up, to make the text shorter, while keeping (most of) the
content.  I pushed these changes to the flubber repository,
tschwinge/gsoc branch.  I plan to merge that into master in a day or two,
unless someone (Olaf) objects.  (I'm open to discuss these changes, of
course -- that's why I put them into a separate branch.)

> the student application template,
> 
>http://www.bddebian.com/~hurd-web/community/gsoc/student_application_form/
> 
> and the project ideas list,
> 
>http://www.bddebian.com/~hurd-web/community/gsoc/project_ideas/

Not yet reviewed.


> Also, we need a backup organisation administrator. Any takers?

Me.  Unless someone objects, I'll add my link ID to the page.


Regards,
 Thomas


signature.asc
Description: Digital signature

Hurd vs. Google Summer of Code 2010

[olafBuddenhagen]

Hi,

On Tue, Mar 09, 2010 at 04:08:27PM +0100, Arne Babenhauserheide wrote:

> Has someone already prepared and submitted the application for GSoC
> this year? 

No, but I just spent the better part of the night updating the forms
etc. (which means that I'll be very sleepy at the meeting tomorrow, err,
I mean today -- as usual...); and now wanted to write about it.

I considered offloading this to someone else this year, as I don't
really have time -- but then, most of the stuff from last year can be
reused, so it shouldn't require much new effort... And I trust most
others with such stuff even less then I trust myself ;-) Some help would
be nice though, as always.

The results of my labour are available from

   http://www.bddebian.com/~hurd-web/community/gsoc/

Please take a look at the organisation application form,

   http://www.bddebian.com/~hurd-web/community/gsoc/organization_application/

the student application template,

   http://www.bddebian.com/~hurd-web/community/gsoc/student_application_form/

and the project ideas list,

   http://www.bddebian.com/~hurd-web/community/gsoc/project_ideas/

and make improvements/give some feedback.

Wouldn't hurt to get some new projects on the list either... Please
share your brilliant ideas :-)

Also, we need a backup organisation administrator. Any takers?

The link ID for the backup admin needs to be supplied in the
organisation application form. If you participated (in any role) last
year, you should already have a link ID. Otherwise, please sign in on
the GSoC page ( http://socghop.appspot.com) with your Google account,
and create a user profile -- you will get your link ID in this process.

I think that's it for now. Perhaps we can discuss some things at the
meeting tomorrow... I mean today.

-antrik-

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

Hello,

On Thu, May 21, 2009 at 7:55 PM,   wrote:
> On Sun, May 17, 2009 at 11:21:42PM +0300, Sergiu Ivanov wrote:
>> On Sat, May 16, 2009 at 11:45 PM,   wrote:
>> > On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:
>
>> > The idea was to create new branches in the existing unionfs
>> > repository, rather than creating another repository.
>>
>> Hm... I have a conceptual question, then: do I understand it right
>> that unionmount will become a kind of a child project of unionfs?
>
> Uhm, no... You are right of course: Creating a new branch in the unionfs
> repository is not really the right thing in the long run.
>
> As discussed on IRC, I believe that both unionfs and unionmount should
> ultimately live in different directories of the main Hurd repository.

I see... Thank you for the explanation.

> (I'm not sure why unionfs was put on hurdextras in the first place --
> there seems to be no problem with copyright assignments, so it can be
> included in the main repository just fine...)

I'm afraid Thomas could be against moving unionfs (and unionmount,
probably, too) into the main repository...

>> And another one (not conceptual already): does having a Savannah
>> account suffice to create a new branch in the existing unionfs
>> repository?
>
> Having a Savannah account doesn't suffice for that; but having write
> permissions on the Hurd repositories does. You should have gotten that
> last summer...

Great :-) And yep, Thomas granted me write permission last
summer. Thanks for the information :-)

Regards,
scolobb

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[olafBuddenhagen]

Hi,

On Sun, May 17, 2009 at 11:21:42PM +0300, Sergiu Ivanov wrote:
> On Sat, May 16, 2009 at 11:45 PM,   wrote:
> > On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:

> > The idea was to create new branches in the existing unionfs
> > repository, rather than creating another repository.
> 
> Hm... I have a conceptual question, then: do I understand it right
> that unionmount will become a kind of a child project of unionfs?

Uhm, no... You are right of course: Creating a new branch in the unionfs
repository is not really the right thing in the long run.

As discussed on IRC, I believe that both unionfs and unionmount should
ultimately live in different directories of the main Hurd repository.

(I'm not sure why unionfs was put on hurdextras in the first place --
there seems to be no problem with copyright assignments, so it can be
included in the main repository just fine...)

> And another one (not conceptual already): does having a Savannah
> account suffice to create a new branch in the existing unionfs
> repository?

Having a Savannah account doesn't suffice for that; but having write
permissions on the Hurd repositories does. You should have gotten that
last summer...

-antrik-

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

Hello,

On Sat, May 16, 2009 at 11:45 PM,   wrote:
> On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:
>
>> >> FYI, I want to create a new repository at github...
>> >
>> > Of course you're free to do that, but why not simply use the
>> > Savannah repository?
>>
>> Oh, I was thinking of that, but I don't really have Savannah
>> experience. I have a Savannah account, is that enough to create this
>> new repository?..
>
> The idea was to create new branches in the existing unionfs repository,
> rather than creating another repository.

Hm... I have a conceptual question, then: do I understand it right
that unionmount will become a kind of a child project of unionfs?

And another one (not conceptual already): does having a Savannah
account suffice to create a new branch in the existing unionfs
repository?

> Also note that you needn't bother about that until you actually have
> changes to push. But before you push anything, I wanted to discuss some
> policies at the next IRC meeting... (Actually, I wanted to discuss this
> at the previous one; but I forgot :-( )

OK, that's not a problem. We are meeting on Tuesday, May 19, and it's
not that far away :-)

In the meantime, I'll have a look at dir_lookup problem and stuff in
nsmux, and into the features of unionfs which we could strip down for
unionmount.

Regards,
scolobb

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[olafBuddenhagen]

Hi,

On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:

> >> FYI, I want to create a new repository at github...
> >
> > Of course you're free to do that, but why not simply use the
> > Savannah repository?
> 
> Oh, I was thinking of that, but I don't really have Savannah
> experience. I have a Savannah account, is that enough to create this
> new repository?..

The idea was to create new branches in the existing unionfs repository,
rather than creating another repository.

Also note that you needn't bother about that until you actually have
changes to push. But before you push anything, I wanted to discuss some
policies at the next IRC meeting... (Actually, I wanted to discuss this
at the previous one; but I forgot :-( )

-antrik-

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

> On Fri, May 15, 2009 at 09:25:54PM +0300, Sergiu Ivanov wrote:
>> On Tue, Apr 28, 2009 at 1:42 AM, Thomas Schwinge  wrote:
>> >  -- but please do not 
>> > yet
>> > push changes there.
>
> I see no reason to any longer hold off with pushing changes into this
> particular repository.  However, this doesn't mean that it's also true
> for the other Hurd repositories (which I might still decide to
> re-convert).

OK, thank you for the information. I'll keep that in mind.

>> I beg my pardon for a bit of a silly question: if I want to fork
>> unionfs from this repository, should I use git clone, git checkout or
>> git fetch to get the source files from the repository you
>> created?.. And, unfourtunately, I'm rather at a loss as to what should
>> come next...
>
> Here's what one'd do if going with my suggestions from
> :
>
>$ git clone --no-checkout 
> ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git
>$ cd unionfs/
>$ git checkout -b TAG origin/master
>$ ...
>$ git push TAG
>
> TAG would either be master-scolobb, or master-scolobb-FEATURE1, or
> master-scolobb-gsoc2009, or master-scolobb-gsoc2009-FEATURE1, or simply
> master-FEATURE1, or...

Thanks a lot! I'll try that shortly.

>> FYI, I want to create a new repository at github...
>
> Of course you're free to do that, but why not simply use the Savannah
> repository?

Oh, I was thinking of that, but I don't really have Savannah
experience. I have a Savannah account, is that enough to create this
new repository?.. And, also, creating a Savannah repository for
unionmount will mean another series of questions regarding this
matter... Are you ready to stand another couple of these? ;-)

Regards,
scolobb

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Fri, May 15, 2009 at 09:25:54PM +0300, Sergiu Ivanov wrote:
> On Tue, Apr 28, 2009 at 1:42 AM, Thomas Schwinge  wrote:
> >  -- but please do not 
> > yet
> > push changes there.

I see no reason to any longer hold off with pushing changes into this
particular repository.  However, this doesn't mean that it's also true
for the other Hurd repositories (which I might still decide to
re-convert).


> I beg my pardon for a bit of a silly question: if I want to fork
> unionfs from this repository, should I use git clone, git checkout or
> git fetch to get the source files from the repository you
> created?.. And, unfourtunately, I'm rather at a loss as to what should
> come next...

Here's what one'd do if going with my suggestions from
:

$ git clone --no-checkout 
ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git
$ cd unionfs/
$ git checkout -b TAG origin/master
$ ...
$ git push TAG

TAG would either be master-scolobb, or master-scolobb-FEATURE1, or
master-scolobb-gsoc2009, or master-scolobb-gsoc2009-FEATURE1, or simply
master-FEATURE1, or...

> FYI, I want to create a new repository at github...

Of course you're free to do that, but why not simply use the Savannah
repository?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

Hello,

On Tue, Apr 28, 2009 at 1:42 AM, Thomas Schwinge  wrote:
>  -- but please do not yet
> push changes there.

I beg my pardon for a bit of a silly question: if I want to fork
unionfs from this repository, should I use git clone, git checkout or
git fetch to get the source files from the repository you
created?.. And, unfourtunately, I'm rather at a loss as to what should
come next...

FYI, I want to create a new repository at github...

Regards,
scolobb

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

Hello,

Thomas Schwinge  writes:
> On Thu, Apr 23, 2009 at 09:49:01AM +0200, I wrote:
>> So, I'd rather go for the conversion method, to not hide the previous
>> history.  And, as I'm already in this dirty business -- a bunch of the
>> main Hurd's repositories and their branches have already been published,
>> by the way -- I'm hereby offering to do the conversion for you.  Stay
>> tuned.
>
>  -- but please do not yet
> push changes there.

Thank you very much :-) I do not intend to do any changes to unionfs
right now, so at the moment this limitation is not critical.

Anyways, I'd be very grateful if you could announce me when the unionfs
git repository is ready for pushing, since I consider it very much
possible that I will be doing (at least) some bug-fixes, which may go
into unionfs, as well as being useful in unionmount itself.

Regards,
scolobb

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Thu, Apr 23, 2009 at 09:49:01AM +0200, I wrote:
> So, I'd rather go for the conversion method, to not hide the previous
> history.  And, as I'm already in this dirty business -- a bunch of the
> main Hurd's repositories and their branches have already been published,
> by the way -- I'm hereby offering to do the conversion for you.  Stay
> tuned.

 -- but please do not yet
push changes there.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Sergiu Ivanov]

Hello,

Thomas Schwinge  writes:
> On Wed, Apr 22, 2009 at 02:05:44PM +0300, Sergiu Ivanov wrote:
>> I'm going to start implementing the VFS-style union mount functionality
>> (http://preview.tinyurl.com/cpftg2).
>
> Congratulations for having gotten this GSoC project accepted!  Sergiu
> will be our only GSoC student for this summer.  As he has, through his
> previous work, already proven during the last year that he's capable of
> working on Hurd stuff, I have no doubt that it will be a success both for
> him and for us.  :-)

Thank you very much for such flattering appreciation! :-) I'll strive
hard to satisfy the expectations to the maximal degree :-)

>> The current strategy is based on
>> forking off the unionfs code base (retrieved from
>> http://www.nongnu.org/hurdextras/#unionfs). I am going (rather
>> naturally) to use git as the VCS for my project, which rises the
>> following question: how do I do the forking itself? Do I have to convert
>> the CVS repository of unionfs to git, or may I create an empty
>> repository, do a big push of all unionfs code there, and start working
>> in this repository?
>
> As far as I can tell, from a quick inspection, the copyright for all
> changes to the unionfs code is assigned to the FSF, so we can safely
> import that next to the main Hurd repositories.
>
> So, I'd rather go for the conversion method, to not hide the previous
> history.  And, as I'm already in this dirty business -- a bunch of the
> main Hurd's repositories and their branches have already been published,
> by the way -- I'm hereby offering to do the conversion for you.  Stay
> tuned.

I was also thinking about conversion, but it looked a bit frightening,
so I appreciate your proposal very much and I'll feel very much obliged
if you would help me in this matter :-)

Regards,
scolobb

Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Wed, Apr 22, 2009 at 02:05:44PM +0300, Sergiu Ivanov wrote:
> I'm going to start implementing the VFS-style union mount functionality
> (http://preview.tinyurl.com/cpftg2).

Congratulations for having gotten this GSoC project accepted!  Sergiu
will be our only GSoC student for this summer.  As he has, through his
previous work, already proven during the last year that he's capable of
working on Hurd stuff, I have no doubt that it will be a success both for
him and for us.  :-)


> The current strategy is based on
> forking off the unionfs code base (retrieved from
> http://www.nongnu.org/hurdextras/#unionfs). I am going (rather
> naturally) to use git as the VCS for my project, which rises the
> following question: how do I do the forking itself? Do I have to convert
> the CVS repository of unionfs to git, or may I create an empty
> repository, do a big push of all unionfs code there, and start working
> in this repository?

As far as I can tell, from a quick inspection, the copyright for all
changes to the unionfs code is assigned to the FSF, so we can safely
import that next to the main Hurd repositories.

So, I'd rather go for the conversion method, to not hide the previous
history.  And, as I'm already in this dirty business -- a bunch of the
main Hurd's repositories and their branches have already been published,
by the way -- I'm hereby offering to do the conversion for you.  Stay
tuned.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Google Summer of Code 2009

[olafBuddenhagen]

Hi,

On Sat, Mar 07, 2009 at 09:20:00AM +0100, olafbuddenha...@gmx.net wrote:

> I believe the friendly smileys to have an important psychological
> effect: they have the express purpose of making the text less formal and
> thus intimidating.

Of course any other suggestion for making the texts less intimidating
are also welcome -- as in fact any comments on the organisation
application,

   
http://www.bddebian.com:/~hurd-web/community/gsoc/organization_application/

the student application form,

   
http://www.bddebian.com:/~hurd-web/community/gsoc/student_application_form/

and the project ideas list:

   http://www.bddebian.com:/~hurd-web/community/gsoc/project_ideas/

But don't hesitate too long: I'll be submitting the application early on
Friday -- I'm leaving for the weekend, so I won't wait till the
deadline. The organisation application is final then, and the other two
should also be close to final. (Though some readjustment to the latter
will be possible for a few days more.)

I'm waiting for your feedback!

-antrik-

Re: Google Summer of Code 2009

[Samuel Thibault]

Hello,

Thomas Schwinge, le Fri 06 Mar 2009 12:52:04 +0100, a écrit :
> Also, we need mentors.  Samuel?

Sure.

Samuel

Re: Google Summer of Code 2009

[Evgeniy Ivanov]

Hi,

On Sat March 7 2009 11:20:00 olafbuddenha...@gmx.net wrote:
> Hi,
>
> On Fri, Mar 06, 2009 at 12:52:04PM +0100, Thomas Schwinge wrote:
> > I do know that Olaf likes to use them, but what about making these
> > texts more formally appealing and remove all (or most of) the smileys?
>
> I can only repeat my petition to disable this idiotic image replacement
> -- it indeed makes the smileys look silly.
>
> However, I object to removing the smileys. I put them in for a reason:
> liking them has nothing to do with it.
>
> These pages are for the potential students to read. Many of them are new
> to free software development, and most of them are rather awed by it. An
> overly formal text would only make it worse. Our requirements for the
> application are probably intimidating enough without it -- we should do
> everything possible to counteract that!
>
> I believe the friendly smileys to have an important psychological
> effect: they have the express purpose of making the text less formal and
> thus intimidating.

As a former GSoCer I can confirm it. More than that: it's important for people 
who are new to your community, but not just to free software.
As we discovered with Sergey at the meeting: every organization has its own 
outstanding characteristics, so people always think: who are that guys doing 
Hurd? And smileys are really friendly (except those ugly gifs).


-- 
Best regards, Evgeniy.
Key Fingerprint: F316B5A1F6D2054FCD18B74A95400ABB1FE567A3



signature.asc
Description: This is a digitally signed message part.

Re: Google Summer of Code 2009

[olafBuddenhagen]

Hi,

On Fri, Mar 06, 2009 at 12:52:04PM +0100, Thomas Schwinge wrote:

> I do know that Olaf likes to use them, but what about making these
> texts more formally appealing and remove all (or most of) the smileys?

I can only repeat my petition to disable this idiotic image replacement
-- it indeed makes the smileys look silly.

However, I object to removing the smileys. I put them in for a reason:
liking them has nothing to do with it.

These pages are for the potential students to read. Many of them are new
to free software development, and most of them are rather awed by it. An
overly formal text would only make it worse. Our requirements for the
application are probably intimidating enough without it -- we should do
everything possible to counteract that!

I believe the friendly smileys to have an important psychological
effect: they have the express purpose of making the text less formal and
thus intimidating.

> Olaf, again, I'm not sure if I mentioned this already: I'd offer to
> fulfill the administrator role again.

I don't think you mentioned it yet -- but I'm glad to hear it :-)

How about actually mentoring as well? I don't want to supervise four
students myself again...

(The projects can only really go well if someone is checking the
students' work properly and in a timely manner. I simply don't have the
time and energy to do this alone for so many students. We fared very
poorly in this regard last year: although the students did very good
work on the whole, none of it -- except for some of Andrei's patches --
has been merged into mainline yet. I really hope we can do better this
time...)

-antrik-

Google Summer of Code 2009

[Thomas Schwinge]

Hello!

On Fri, Mar 06, 2009 at 10:57:32AM +0100, Arne Babenhauserheide wrote:
> Am Freitag 06 März 2009 06:32:44 schrieb olafbuddenha...@gmx.net:
> > > downloaded more than 2000 times last month.
> >
> > Interesting -- I wonder where these come from :-)
> 
> Same for me, but I generally only access my logs via the supplied usage 
> statistics, so I can't easily check the full logs. 

Perhaps Google is indexing ISO images by now?  ;-)


> > > Besides: Is anyone already working on an application for GSoC 2009?
> >
> > Yes, I started a couple of days ago. (Yeah, my reply is a bit late... It
> > would have been "not yet", if I had replied timely ;-) )
> 
> Many thanks for taking it up! 
> 
> I'll gladly doublecheck and proofread it; please post, once you get to a 
> point, where we can comment on it. 

It's in the web pages (former wiki) repository, in community/gsoc/.  I do
know that Olaf likes to use them, but what about making these texts more
formally appealing and remove all (or most of) the smileys?


Olaf, again, I'm not sure if I mentioned this already: I'd offer to
fulfill the administrator role again.


Also, we need mentors.  Samuel?  Others?  Neal, do you want to come up
with projects for viengoos?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Server overriding; chroot (was: Google Summer of Code participation)

[Wei Shen]

Hi,

On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > I also find "secure chroot implementation" in the list. IMHO, the
> > unsafty of chroot is not caused by passive translator. In fact,
> > currently chroot is implemented totally at client side by changing the
> > INIT_PORT_CRDIR port matained by in Glibc. So, it is easy to escape
> > from chroot by bypassing the file port resolving routine of Glibc, or
> > just by modifying the CRDIR port. No need to exploit passive
> > translators at all. We should first let the file server know and
> > control chroot before making translators aware of it.
>
> That's not true as far as I know. Of course, the process can easily
> change it's own idea of what the root directory is. But that doesn't
> help escaping the chroot. To access anything outside the chroot, the
> process needs a port to the outside filesystem...


You are right. I previously tried to hack Glibc chroot routine to preserve
the original root port before changing root, so I can escape, but right, it
is certainly what chroot considers and wants to prevent.

Regards,
Wei Shen

Re: Server overriding; chroot (was: Google Summer of Code participation)

[Pierre THIERRY]

Scribit [EMAIL PROTECTED] dies 18/03/2008 hora 16:38:
> Now the problem is that a chrooted process can create a passive
> translator. When this translated node is accessed, the translator
> process currently won't be started in the context of the chrooted
> process, but in that of the normal global filesystem -- it has access
> to everything, and can pass it on to the chrooted process.

That really calls for capability discipline in the Hurd interfaces, I'd
say (I'm not sure, but it may have been one of the reason the developers
of the L4 port looked at capabilities). If the translator had to provide
an explicit capability (whatever it would be in this case) that
designate what it accesses, it should be relatively easier to secure the
chroot.

As I don't know the details of the communications between translators
and the filesystem, I wonder: is there a documentation about it?

Curiously,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Server overriding; chroot (was: Google Summer of Code participation)

[olafBuddenhagen]

Hi,

On Sun, Mar 16, 2008 at 12:47:23AM +0800, Wei Shen wrote:

> I read the project ideas list, and found "server overriding mechanism"
> is there. I have once tried investigating this issue, but failed to
> continue at last. Still, I wonder whether I should submit my
> modification to Glibc for an simple implementation of socket server
> overriding, though the work is rather minor (see attachment).

Well, it can certainly serve as a starting point :-)

> I also find "secure chroot implementation" in the list. IMHO, the
> unsafty of chroot is not caused by passive translator. In fact,
> currently chroot is implemented totally at client side by changing the
> INIT_PORT_CRDIR port matained by in Glibc. So, it is easy to escape
> from chroot by bypassing the file port resolving routine of Glibc, or
> just by modifying the CRDIR port. No need to exploit passive
> translators at all. We should first let the file server know and
> control chroot before making translators aware of it.

That's not true as far as I know. Of course, the process can easily
change it's own idea of what the root directory is. But that doesn't
help escaping the chroot. To access anything outside the chroot, the
process needs a port to the outside filesystem...

When creating a chroot, the port to the desired virtual root directory
is obtained, and the filesystem server responsible for that directory is
told -- by means of the file_reparent() RPC -- to treat it as if it was
indeed a root directory; i.e. instead of following lookups for "..",
just return the same directory. This way, in theory the chrooted process
should never be able to access anything above it's virtual root.

Now the problem is that a chrooted process can create a passive
translator. When this translated node is accessed, the translator
process currently won't be started in the context of the chrooted
process, but in that of the normal global filesystem -- it has access to
everything, and can pass it on to the chrooted process.

There have been discussions about that in the past (unfortunately not
linked from the task description, though I hope that can be fixed
still...), and many possible solutions have been proposed. The hard part
is deciding on the best solution, and demonstrating in a convincing
fashion, that it indeed solves the problem. (Many of my suggested
solutions have been refused in the past, though only based on
misunderstanding I believe...)

-antrik-

Re: Google Summer of Code participation

[olafBuddenhagen]

Hi,

On Tue, Mar 11, 2008 at 10:03:29PM +0100, Carl Fredrik Hammar wrote:
> <[EMAIL PROTECTED]> writes:

> > You would soon have to decide whether you want to apply as student
> > again, or mentor the project. (Or just do it independently as you
> > planned...) It's not possible to do both :-)
> 
> But I could mentor it and be a student for another project.  ;-)

Well, not as official mentor at least. Google doesn't allow being both
mentor and student at the same time.

-antrik-

Re: Google Summer of Code participation

[Wei Shen]

Hi,

I read the project ideas list, and found "server overriding mechanism" is
there. I have once tried investigating this issue, but failed to continue at
last. Still, I wonder whether I should submit my modification to Glibc for
an simple implementation of socket server overriding, though the work is
rather minor (see attachment).

I also find "secure chroot implementation" in the list. IMHO, the unsafty of
chroot is not caused by passive translator. In fact, currently chroot is
implemented totally at client side by changing the INIT_PORT_CRDIR port
matained by in Glibc. So, it is easy to escape from chroot by bypassing the
file port resolving routine of Glibc, or just by modifying the CRDIR port.
No need to exploit passive translators at all. We should first let the file
server know and control chroot before making translators aware of it.

>

>  I made a try to implement a basic mechanism of socket servers  (pfinet
> and pflocal) overriding, as described below. Comments are solicited.
>
>  1) Add two new environment variables: SERVERS_SOCKET_LOCAL for the
> pf_local socket server and SERVERS_SOCKET_INET for the pf_inet server. The
> value of each variable should be set to a colon-separated list, and each
> element of the list is a file path that specifies a overriding server.
>
> 2) Hack *_hurd_socket_server* in "hurd/hurdsock.c" of Glibc to check for
> the two environment variables.
>
>
  For example, when looking up the socket server of pf_inet domain, *
> _hurd_socket_server* first checks SERVERS_SOCKET_INET. If
> SERVERS_SOCKET_INET is not set or is set to null, then just queries and
> returns the port of the default pf_inet server as usual; or else, repeatedly
> tries querying each overriding server in the overriding list defined by
> SERVERS_SOCKET_INET, until the first existing overriding server is found (or
> none is found).
>

>  The modified hurd/hurdsock.c is attached to this mail. I have tested it
> with Glibc-2.5.
>
>

Regards,

Wei Shen


hurdsock.c
Description: Binary data

Re: Google Summer of Code participation

[Carl Fredrik Hammar]

Hi,

<[EMAIL PROTECTED]> writes:

>> > Especially the project list needs work. Some of the project
>> > descriptions are only skeletons; I lack the knowledge to fill in the
>> > details. But I know that some of you have much better understanding
>> > about some of these projects.
>> 
>> I noticed ``Translator stacking mechanism'' in there.  I'm planning on
>> getting some serious work done on this soon, as I'm just getting out
>> of a particularly stressful quarter (just one exam left now :-), and
>> I'm entering a particularly calm quarter and I will have plenty of
>> spare time on my hands.
>
> Oh, I didn't know that. Good to hear, though :-)
>
> In this case, maybe it's better to take it off the ideas list
> alltogether...

I took it down.  Since I'm most suited for the project (and obviously
already familiar with it), and since I'd rather do it individually
then mentor someone else doing it.  (Bringing a student up to speed
seems almost as much work as just doing it myself.  :-)

> It's not like there are no other project ideas :-)

Indeed, the list is actually quite impressive.  If nothing else we
should be accepted as an organization simply because there's so much
to do.  :-)

>> So I'm not sure how much will be left for a student to do.  But then
>> again life happens, and should I fail to get started with it, it would
>> be a nice project.
>
> Well, we could still propose the task again for next year's SoC, if it
> turns out you can't do it after all. By no means I want to take this
> project away from you :-)

This is reasonable, I wouldn't consider it a high priority project
that needs to be completed any time soon.

>> Of course, I'm more than willing to sign up for another GSoC to get
>> this done if we have a shortage of volunteers.  ;-)
>
> I was actually partially thinking of that when putting it in there.
>
> There is no guarantee however that the project would actually get
> accepted. I very much doubt that we could find someone better for this
> task than you, considering the knowledge you already have about it, and
> the good work you did previously... But then, we do not know yet how
> many brilliant students will sign up for the other tasks :-) The limited
> number of available slots always makes it a tough choice...

The best outcome of GSoC would be new long term contributers, so I
think it's best for me to step aside and let someone else have the
slot.

I would only be comfortable with taking a slot if we were given
unexpectedly many slots, or there were only a few or iffy
applications.  But this seems unlikely, so I don't think I'll waste
time writing an application /just in case/.

>> Not sure if I'm experienced enough to be an actual mentor, but I'm
>> more than willing help out when it comes to fitting the ``Sound
>> support'' and ``TCP/IP stack'' projects into the translator stacking
>> framework.
>
> Well, to fit something into it, first the framework needs to exist :-)

I would be developing it in parallel, of course.  :-)

> Unlike some others, I do not believe that libchannel is a prerequisite
> to implement these things. On the contrary, I think it makes more sense
> to implement them as standalone translators first, and only think of
> optimized stacking mechanisms later on.

Agreed.

> In fact, I think that it would be better even to have the actual
> applications there before writing the stacking framework -- much better
> to test it in the actual use cases, rather than designing it on a purely
> abstract basis, and trying to fit the applications into that later on...

This is closer to what I meant to say, perhaps I should have said
``fit them together'', i.e. making changes to both.

> You would soon have to decide whether you want to apply as student
> again, or mentor the project. (Or just do it independently as you
> planned...) It's not possible to do both :-)

But I could mentor it and be a student for another project.  ;-)

Regards,
  Fredrik

Re: Google Summer of Code participation

[olafBuddenhagen]

Hi,

On Sun, Mar 09, 2008 at 11:43:12PM +0100, Carl Fredrik Hammar wrote:
> <[EMAIL PROTECTED]> writes:

> > Especially the project list needs work. Some of the project
> > descriptions are only skeletons; I lack the knowledge to fill in the
> > details. But I know that some of you have much better understanding
> > about some of these projects.
> 
> I noticed ``Translator stacking mechanism'' in there.  I'm planning on
> getting some serious work done on this soon, as I'm just getting out
> of a particularly stressful quarter (just one exam left now :-), and
> I'm entering a particularly calm quarter and I will have plenty of
> spare time on my hands.

Oh, I didn't know that. Good to hear, though :-)

In this case, maybe it's better to take it off the ideas list
alltogether...

It's not like there are no other project ideas :-)

> So I'm not sure how much will be left for a student to do.  But then
> again life happens, and should I fail to get started with it, it would
> be a nice project.

Well, we could still propose the task again for next year's SoC, if it
turns out you can't do it after all. By no means I want to take this
project away from you :-)

> Of course, I'm more than willing to sign up for another GSoC to get
> this done if we have a shortage of volunteers.  ;-)

I was actually partially thinking of that when putting it in there.

There is no guarantee however that the project would actually get
accepted. I very much doubt that we could find someone better for this
task than you, considering the knowledge you already have about it, and
the good work you did previously... But then, we do not know yet how
many brilliant students will sign up for the other tasks :-) The limited
number of available slots always makes it a tough choice...

> > Also the mentor list inside the organisation application (
> > http://www.bddebian.com/~wiki/community/gsoc/organization_application/
> > ) is still pretty incomplete -- please speak up if you are willing
> > to mentor.
> 
> Not sure if I'm experienced enough to be an actual mentor, but I'm
> more than willing help out when it comes to fitting the ``Sound
> support'' and ``TCP/IP stack'' projects into the translator stacking
> framework.

Well, to fit something into it, first the framework needs to exist :-)
So that would probably be a followup task for next year or so...

Unlike some others, I do not believe that libchannel is a prerequisite
to implement these things. On the contrary, I think it makes more sense
to implement them as standalone translators first, and only think of
optimized stacking mechanisms later on.

In fact, I think that it would be better even to have the actual
applications there before writing the stacking framework -- much better
to test it in the actual use cases, rather than designing it on a purely
abstract basis, and trying to fit the applications into that later on...

> Of course, if a student beats me to it I might be able to mentor
> ``Translator stacking mechanism''.

I've also been considering this possibility. Of course you are still
pretty new to the Hurd project yourself; but on this specific topic, you
are *the* expert now :-) So maybe indeed it would be good to have you
mentor it...

You would soon have to decide whether you want to apply as student
again, or mentor the project. (Or just do it independently as you
planned...) It's not possible to do both :-)

-antrik-

Re: Google Summer of Code participation

[Carl Fredrik Hammar]

Hello,

<[EMAIL PROTECTED]> writes:

> Hi,
>
> For those who haven't heard it yet on IRC (and also a reminder for the
> others): Unlike the last two years, when we only participated under the
> umbrella of the GNU project, this year we want to participate in GSoC as
> an organisation on our own.

This is a great idea!

> Especially the project list needs work. Some of the project descriptions
> are only skeletons; I lack the knowledge to fill in the details. But I
> know that some of you have much better understanding about some of these
> projects.

I noticed ``Translator stacking mechanism'' in there.  I'm planning on
getting some serious work done on this soon, as I'm just getting out
of a particularly stressful quarter (just one exam left now :-), and
I'm entering a particularly calm quarter and I will have plenty of
spare time on my hands.

So I'm not sure how much will be left for a student to do.  But then
again life happens, and should I fail to get started with it, it would
be a nice project.  For now, I've added a disclaimer that student
should contact me if interested.

Of course, I'm more than willing to sign up for another GSoC to get
this done if we have a shortage of volunteers.  ;-)

> Also the mentor list inside the organisation application (
> http://www.bddebian.com/~wiki/community/gsoc/organization_application/ )
> is still pretty incomplete -- please speak up if you are willing to
> mentor.

Not sure if I'm experienced enough to be an actual mentor, but I'm
more than willing help out when it comes to fitting the ``Sound
support'' and ``TCP/IP stack'' projects into the translator stacking
framework.

Of course, if a student beats me to it I might be able to mentor
``Translator stacking mechanism''.


Also this reminded me that I was asked to write an entry about my
experience of last years GSoC.  I wrote a quick draft and then
completely forgot!  I think this would be a great time to finish it
and put on the wiki.  ;-)

Regards,
  Fredrik

Google Summer of Code participation

[olafBuddenhagen]

Hi,

For those who haven't heard it yet on IRC (and also a reminder for the
others): Unlike the last two years, when we only participated under the
umbrella of the GNU project, this year we want to participate in GSoC as
an organisation on our own.

I don't know whether this will result in getting more than the single
slot we got with the GNU project. But it definitely means that we can
have a more targetted student selection process, and generally get more
prominent exposure. (If we get accepted...) These facts should suffice
to make it worthwhile.

I've put up an overview page on,

   http://www.bddebian.com/~wiki/community/gsoc/

but not much there yet. More importantly, I created drafts for our
application as an organization,

   http://www.bddebian.com/~wiki/community/gsoc/organization_application/

the list of project ideas,

   http://www.bddebian.com/~wiki/community/gsoc/project_ideas/

and the application template for the students:

   http://www.bddebian.com/~wiki/community/gsoc/student_application_form/

They are very rough drafts, and need input from others (you). It's a
wiki, meaning anyone can edit it -- please make use of this possibility!

Especially the project list needs work. Some of the project descriptions
are only skeletons; I lack the knowledge to fill in the details. But I
know that some of you have much better understanding about some of these
projects.

Most notably, many of the projects need links to relevant information,
like bug/task tracker items, previous mailing list discussions,
documentation etc. I know that some of you, unlike myself, keep track of
such links, so please add them where appropriate!

Of course, further project ideas are welcome -- the more the better.

Also the mentor list inside the organisation application (
http://www.bddebian.com/~wiki/community/gsoc/organization_application/ )
is still pretty incomplete -- please speak up if you are willing to
mentor.

Note that being in the list doesn't necessarily mean you will actually
be assigned as mentor; it only indicates that you are generally willing
to mentor some of the listed projects. (If you have other project ideas,
please add them to the list!)

I need your google account address to add you -- or better even, just
add yourself.

-antrik-

Carl Fredrik Hammar to work on libchannel (was: Google Summer of Code 2007)

[Thomas Schwinge]

Hello!

bug-hurd, please welcome Carl Fredrik Hammar, who will be working on
<http://savannah.gnu.org/task/?1619>, ``designing and writing libchannel,
a library for streams'', as a Google Summer of Code 2007 project.

Richard Braun will officially be his mentor, but of course we all will
support them.

Giving Fredrik a warm welcome shouldn't be too difficult given that he
had already previously introduced himself and his proposal on this very
mailing list.


Some rules.  They may be rather obvious, but let's nevertheless write
them down here.

Mentoring shall take place on the public <[EMAIL PROTECTED]> mailing list
(save organizational or personal issues, of course), so that everyone can
contribute to the process and also that everyone else can learn
alongside.

The student shall post reports of his efforts to the mailing list.  While
reserving that right, we won't come up with a fixed interval right now,
but the student should at least post his status when requested by the
mentor.  (If there are discussions going on, these are of course already
a statement about the project's status.)


Well then, let the fun begin!  Good luck, Fredrik!

Regards,
 Thomas and Richard


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd

SoC tasks (was: Re: rpctrace improvement for the Google Summer of Code)

[olafBuddenhagen]

Hi,

On Thu, Mar 22, 2007 at 02:16:20AM +0100, Thomas Schwinge wrote:
> On Wed, Mar 21, 2007 at 08:09:31AM +0100, [EMAIL PROTECTED]
> wrote:

> > However, I didn't propose this so far, as tschwinge seems to have a
> > perfectly opposite opinion than me on what are suitable tasks and
> > what aren't.
> 
> Huh, what's that?
> 
> In fact, what I told you was that I wouldn't know how to wrap what you
> suggested into a concise wording for a GSoC task, so that someone who
> isn't familiar with all those Hurd details would know what this task
> was about.  I then asked you to come up with such a wording to then
> install that task, but, so far, you didn't respond to that plea and
> instead now accuse me to not consider your ideas worthwhile?

This wasn't meant to be an accusation. Sorry if I made it sound like
one.

The point is that various comments you made on my proposal as well as
others, made me conclude that you have totally different opinions about
what is appropriate for a SoC task.

As for that other proposal, your intial comment sounded very much like
you do not consider it a suitable task at all; when I asked (on IRC) why
you think so, you suggested I write something up, but didn't follow up
on my questions. I'm still not sure what you really want, when talking
about "concise wording".

I don't know how the proposals are presented to the students. When we
gathered ideas for GGI, we had a single sentence/wordgroup as title for
each task, and one or more paragraphs explaining it: Introducing the
relevant concepts, pointing out what is missing or what could be
improved, and explaining what the student is supposed to do
specifically.

Anyways, I guess it's too late for this year anyways. Maybe next year.
(Yeah, my fault -- I should have made the proposal much earlier.)

-antrik-


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: rpctrace improvement for the Google Summer of Code

[olafBuddenhagen]

Hi,

On Thu, Mar 22, 2007 at 10:50:49AM +, Tim Retout wrote:
> On Wed, 2007-03-21 at 08:09 +0100, [EMAIL PROTECTED] wrote:

> > Implementing the possibility of attaching rpctrace to running
> > processes, is one possible thing that could be done. But there are
> > many others, like adding ability to rpctrace to show the names of
> > the parameters (needs rpctrace and mig changes); adding some tool(s)
> > that allow logging the interactions between several processes, to
> > help understanding complex problems and/or doing system profiling;
> > interactive RPC debugging tools (possibly as GDB extension); and so
> > on.
> 
> These are all good ideas. The difficulty is, the SoC lasts only three
> months, and "most students need the first month just to get their
> bearings and actually start producing code".[0] It's important to
> choose a project/set of tasks that fit within that timeframe. I
> personally would be hesitant about trying to write a whole new
> debugging tool over the summer - even with a good mentor.

Well, it depends on the student. I can imagine that *some* would be able
to create such a tool in three months, so I think it's not wrong to list
it as a possibility -- as long as it's clear that the student is also
free to choose some of the simpler suggestions.

-antrik-


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: rpctrace improvement for the Google Summer of Code

[Tim Retout]

On Wed, 2007-03-21 at 08:09 +0100, [EMAIL PROTECTED] wrote:
> Implementing the possibility of attaching rpctrace to running processes,
> is one possible thing that could be done. But there are many others,
> like adding ability to rpctrace to show the names of the parameters
> (needs rpctrace and mig changes); adding some tool(s) that allow logging
> the interactions between several processes, to help understanding
> complex problems and/or doing system profiling; interactive RPC
> debugging tools (possibly as GDB extension); and so on.

These are all good ideas. The difficulty is, the SoC lasts only three
months, and "most students need the first month just to get their
bearings and actually start producing code".[0] It's important to choose
a project/set of tasks that fit within that timeframe. I personally
would be hesitant about trying to write a whole new debugging tool over
the summer - even with a good mentor.

The rpctrace ideas are my personal favourites at the moment - they have
well-defined ends - you know when and whether you've finished. The only
question then is, can you finish in eight weeks? I'm trying to get a
feel for how large these tasks are, before committing to any of them.

[0] http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors

-- 
Tim Retout <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: rpctrace improvement for the Google Summer of Code

[Thomas Schwinge]

Hello!

On Wed, Mar 21, 2007 at 08:09:31AM +0100, [EMAIL PROTECTED] wrote:
> Implementing the possibility of attaching rpctrace to running processes,
> is one possible thing that could be done. But there are many others,
> like adding ability to rpctrace to show the names of the parameters
> (needs rpctrace and mig changes); adding some tool(s) that allow logging
> the interactions between several processes, to help understanding
> complex problems and/or doing system profiling; interactive RPC
> debugging tools (possibly as GDB extension); and so on.
> 
> However, I didn't propose this so far, as tschwinge seems to have a
> perfectly opposite opinion than me on what are suitable tasks and what
> aren't.

Huh, what's that?

In fact, what I told you was that I wouldn't know how to wrap what you
suggested into a concise wording for a GSoC task, so that someone who
isn't familiar with all those Hurd details would know what this task was
about.  I then asked you to come up with such a wording to then install
that task, but, so far, you didn't respond to that plea and instead now
accuse me to not consider your ideas worthwhile?  That doesn't fit.

I mean, these are tasks that require a really intimate knowledge of how
the components of a Hurd system interact with each other.  That's not
something where an ``average student'' could make any sense of.

That's at least my opinion on this matter.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: rpctrace improvement for the Google Summer of Code

[olafBuddenhagen]

Hi,

On Tue, Mar 20, 2007 at 11:16:13PM +0100, Richard Braun wrote:

> Here is a proposal for a Google Summer of Code project : rpctrace is
> one of the most useful debugging tools on the Hurd. It could help a
> lot in understanding some of the bugs of the system. Unfortunately, it
> can hardly be used to debug some essential translators because it
> cannot be used to trace already running tasks. I don't know exactly
> how this could be done, so I'm asking : is this technically feasible
> as a GSoC project ?

Actually, I already thought of something like this, though I would
suggest making it a more generic task: Improving Hurd-specific debugging
tools.

Implementing the possibility of attaching rpctrace to running processes,
is one possible thing that could be done. But there are many others,
like adding ability to rpctrace to show the names of the parameters
(needs rpctrace and mig changes); adding some tool(s) that allow logging
the interactions between several processes, to help understanding
complex problems and/or doing system profiling; interactive RPC
debugging tools (possibly as GDB extension); and so on.

However, I didn't propose this so far, as tschwinge seems to have a
perfectly opposite opinion than me on what are suitable tasks and what
aren't.

-antrik-


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code project: libchannel

[Carl Fredrik Hammar]

Thomas Schwinge <[EMAIL PROTECTED]> writes:

> Hello!
>
> On Tue, Mar 20, 2007 at 09:22:12PM +0100, Fredrik Hammar wrote:
>> first up let me introduce myself [...]
>
> Welcome, Fredrik!
>

Thanks!
 
>> get it running on Xen.
>
> That basically works, but still has a number of sharp edges and slippery
> slopes.  But for sure we should document how to get it running at all...

Yeah I gave it a shot in the dark and gave up pretty quickly when it
didn't boot mach, I don't even know if I should change the default
domain builder to something else, let alone how to get Hurd started
after that.

But this isn't an issue I want to tackle at the moment, so lets leave
it at that.

>> Then I proceeded investigating the proposed projects and libchannel
>> is the one that interests me the most.  However it might be a bit
>> more than I can chew...
>
> Nothing is carved in stone: the published tasks are the basis for the
> applicants to build their applications on.  And nobody will stop you from
> contributing further once the GSoC is over.  ;-)

That's a relief I guess, but I wouldn't want to apply for writing half
of libchannel and leave a promise to write the rest later ;-).

>> The main problem is my lack of experience with the Hurd's internals
>> and OSes in general.  But since my studies right now are quite
>> relaxed, I feel I should be able to catch up by the time GsoC starts.
>> I could easily spend 10h a week studying the Hurd and `bonding' with
>> you guys (as Google puts it), and will spend more time than that as
>> needed if it's available.  As a plus studying libstore during this
>> time, which should help me immensely with the design of libchannel,
>> will give me an opportunity to go through and fix some of libstore's
>> documentation.
>
>> So I want a second opinion; should I go for it and write a proposal
>> for a libchannel implementation or should I consider some other
>> project instead?
>
> If you can spend the time on it right now -- applications are open until
> the end of this weekend, I think -- writing and submitting your
> application would indeed be a worthwhile thing to do.  I can -- of course
> -- give absolutely no guarantees that we might select yours, but you'll
> hopefull already learn a lot when writing that application.

Well of course, I wasn't expecting any guarantees of my proposal
getting picked.  On the contrary, I was hoping I didn't get a
guarantees that I wouldn't be picked. ;-)

But since that doesn't seem to be the case, I'll guess I give it my
best shot at writing a proper proposal.  Now I can concentrate on
actually writing the proposal and not look around for alternatives, at
least not until I get this proposal done.

>> PS. I'm new to posting on mailing lists, please excuse and correct any
>> misstakes I make.
>
> Nothing to find fault within so far.  :-)
>
>
> Regards,
>  Thomas

Lets hope it stays that way. :-)

Thanks again,
Fredrik


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code project: libchannel

[Thomas Schwinge]

Hello!

On Tue, Mar 20, 2007 at 09:22:12PM +0100, Fredrik Hammar wrote:
> first up let me introduce myself [...]

Welcome, Fredrik!


> get it running on Xen.

That basically works, but still has a number of sharp edges and slippery
slopes.  But for sure we should document how to get it running at all...


> Then I proceeded investigating the proposed projects and libchannel is
> the one that interests me the most.  However it might be a bit more
> than I can chew...

Nothing is carved in stone: the published tasks are the basis for the
applicants to build their applications on.  And nobody will stop you from
contributing further once the GSoC is over.  ;-)

> The main problem is my lack of experience with the Hurd's internals
> and OSes in general.  But since my studies right now are quite
> relaxed, I feel I should be able to catch up by the time GsoC starts.
> I could easily spend 10h a week studying the Hurd and `bonding' with
> you guys (as Google puts it), and will spend more time than that as
> needed if it's available.  As a plus studying libstore during this
> time, which should help me immensely with the design of libchannel,
> will give me an opportunity to go through and fix some of libstore's
> documentation.

> So I want a second opinion; should I go for it and write a proposal
> for a libchannel implementation or should I consider some other
> project instead?

If you can spend the time on it right now -- applications are open until
the end of this weekend, I think -- writing and submitting your
application would indeed be a worthwhile thing to do.  I can -- of course
-- give absolutely no guarantees that we might select yours, but you'll
hopefull already learn a lot when writing that application.


> PS. I'm new to posting on mailing lists, please excuse and correct any
> misstakes I make.

Nothing to find fault within so far.  :-)


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: rpctrace improvement for the Google Summer of Code

[Marcus Brinkmann]

At Tue, 20 Mar 2007 23:16:13 +0100,
Richard Braun <[EMAIL PROTECTED]> wrote:
> 
> [1  ]
> [1.1  ]
> Hello,
> 
> Here is a proposal for a Google Summer of Code project : rpctrace is one
> of the most useful debugging tools on the Hurd. It could help a lot in
> understanding some of the bugs of the system. Unfortunately, it can
> hardly be used to debug some essential translators because it cannot be
> used to trace already running tasks. I don't know exactly how this could
> be done, so I'm asking : is this technically feasible as a GSoC project ?

It seems to me that this can be achieved transparently to the
monitored task by using the standard Mach interfaces for a task port
(you need the task port for debugging anyway).  There are extensive
interfaces to query and manipulate the port name space of a process,
and that should allow you to retrieve all ports, create wrappers for
them and insert the wrapper objects into the monitored task.  You
should also be able to undo the monitoring by reversing the process.
Care must be taken to suspend the process while doing this, and also
to modify the number of references appropriately.

Please see the sections "Port Names", "Port Rights", "Ports and other
Tasks" in the GNU Mach Reference Manual (gnumach/doc/mach.texi).

Note that this will not allow you to debug all essential translators.
Depending on your environment, debugging a critical server used by
rpctrace itself indirectly would likely be hazardous.  Irregardless of
that, being able to attach and remove a monitor to a process at
runtime is certainly useful.

Thanks,
Marcus



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

rpctrace improvement for the Google Summer of Code

[Richard Braun]

Hello,

Here is a proposal for a Google Summer of Code project : rpctrace is one
of the most useful debugging tools on the Hurd. It could help a lot in
understanding some of the bugs of the system. Unfortunately, it can
hardly be used to debug some essential translators because it cannot be
used to trace already running tasks. I don't know exactly how this could
be done, so I'm asking : is this technically feasible as a GSoC project ?

-- 
Richard Braun


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Google Summer of Code project: libchannel

[Fredrik Hammar]

Hi everyone,

first up let me introduce myself, my name is Fredrik Hammar and I'm a
2:nd year computer science under-graduate at Lund's University here in
Sweden.  My main intrests in the field are OSes, compilers and theory
of programming languages.  Although I've haven't gotten the chance to
study any of those properly yet :(.

I've been interested in the Hurd for quite some time now, I had it
installed and used it about 6 months ago but botched my installation
when I realized PPPoE wasn't available, which made it quite
impractical for me to use.  But not before writing a trivial
translator that returned prime-numbers ;), and signing up a couple of
your mailing lists, mainly to lurk and follow the interesting
discussions about l4-Hurd (and beyond).

I was thinking about how to get by during the summer when I noticed
you guys on as mentors for Google summer of code, which reinvigorated
my interest of the Hurd.  So I reinstalled the Hurd, but this time on
qemu so I don't have to reboot to access the net and later I hope to
get it running on Xen.

Then I proceeded investigating the proposed projects and libchannel is
the one that interests me the most.  However it might be a bit more
than I can chew...

The main problem is my lack of experience with the Hurd's internals
and OSes in general.  But since my studies right now are quite
relaxed, I feel I should be able to catch up by the time GsoC starts.
I could easily spend 10h a week studying the Hurd and `bonding' with
you guys (as Google puts it), and will spend more time than that as
needed if it's available.  As a plus studying libstore during this
time, which should help me immensely with the design of libchannel,
will give me an opportunity to go through and fix some of libstore's
documentation.

Luckily I DO have experience with C, make and autotools, although
mainly on small projects of my own and nothing this big.

All the other suggestions also seem to require similar knowledge of
the Hurd (although not as much) in addition to something else of which
I have little or no experience with (sound, nfs, etc.).  I've also
been considering doing a project on GCC, but I've only come up with
pretty sketchy ideas.

So I want a second opinion; should I go for it and write a proposal
for a libchannel implementation or should I consider some other
project instead?

Eagerly awating response,
Fredrik

PS. I'm new to posting on mailing lists, please excuse and correct any
misstakes I make.






___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Thomas Schwinge]

Hello!

Thanks to all who provided me with comments!


Here is the list I'm going to submit.  We can still change it, based on
your input.



Unfortunately, the Savannah links are down at the moment, but that should
be fixed tomorrow afternoon, the GNU people say.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Pierre THIERRY]

Scribit Thomas Schwinge dies 13/03/2007 hora 17:12:
> > Libchannel is a prerequisitive for many proposed projects. I think
> > that any project that depends on it, should not be proposed. [...] 
> Also correct.  However, if two people that are know to work together
> want to work parallel to each other, say one on libchannel and the
> other on pfinet, then that can only help as both of them then can help
> each other

How would the pfinet work be done without libchannel? How could it be
evaluated in the case of a failure to deliver in the libchannel project?

If a student works on pfinet without libchannel being done, he just
won't be able to test its code even once. That seems pretty dangerous,
for everyone.

Independently,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Thomas Schwinge]

Hello!

On Tue, Mar 13, 2007 at 09:18:32PM +0100, [EMAIL PROTECTED] wrote:
> On Mon, Mar 12, 2007 at 12:27:09AM +0100, Thomas Schwinge wrote:
> > http://savannah.gnu.org/task/?5469 -- Rewrite pfinet
> > 
> > The libchannel project should be done before, or at least in parallel,
> > I'd say.
> [...]
> > http://savannah.gnu.org/task/?5485 -- Design and implement a sound
> > system
> > 
> > Both libchannel and the device driver update should be done before, or
> > at least in parallel, I'd say.
> 
> LIbchannel isn't really necessary for either of these projects. Aside
> from the fact that I still don't see any use in a generic libchannel at
> all, there is nothing wrong with implementing these things
> independently, and later moving them to libchannel if someone really
> feels like implementing it. Libchannel is only an optimization.
> 
> Answering any attempt of implementing sound or improved networking or
> whatever with "write libchannel first" doesn't make any sense.

It seemed right to me that all these stream based services should make
use of a to-be-designed-and-written libchannel.  If that doesn't seem
feasible to you, then please elaborate.


As for ``implementing these things'' -- _I__ would rather prefer to use
(via another layer of glue code) existing code for that, because I think
that maintaining a (e.g.) functional TCP/IP stack (IPv4 and IPv6) seems
to be a rather adventurous venture to me.


> Sound support doesn't really depend on a new driver framework either. It
> requires sound drivers in Mach of course, but that doesn't mean all the
> other drivers need to be updated for that.

Well, but you'll definitely want some upgrades of the basics, like bus
access (pci, etc.) and other framework issues.  And then, you have the
possibility to either adapt the old glue code to that new framework or
provide a glue-in-the-glue code to map the new glue code's functions to
what to old glue code expects...


> Another interesting task: Improve subhurds. (Allow running as root, more
> debug possibilities, sharing of services etc.)

``Allow running as _non_-root'', I guess.  Sure, that'd be a very nice
thing, but again doesn't seem really right for a GSoC project to me.  If
you could come up with a self-contained wording for such a task, then I'm
all ears.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[olafBuddenhagen]

Hi,

On Mon, Mar 12, 2007 at 12:27:09AM +0100, Thomas Schwinge wrote:

> http://savannah.gnu.org/task/?5469 -- Rewrite pfinet
> 
> The libchannel project should be done before, or at least in parallel,
> I'd say.
[...]
> http://savannah.gnu.org/task/?5485 -- Design and implement a sound
> system
> 
> Both libchannel and the device driver update should be done before, or
> at least in parallel, I'd say.

LIbchannel isn't really necessary for either of these projects. Aside
from the fact that I still don't see any use in a generic libchannel at
all, there is nothing wrong with implementing these things
independently, and later moving them to libchannel if someone really
feels like implementing it. Libchannel is only an optimization.

Answering any attempt of implementing sound or improved networking or
whatever with "write libchannel first" doesn't make any sense.

Sound support doesn't really depend on a new driver framework either. It
requires sound drivers in Mach of course, but that doesn't mean all the
other drivers need to be updated for that.

Another interesting task: Improve subhurds. (Allow running as root, more
debug possibilities, sharing of services etc.)

-antrik-


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Thomas Schwinge]

Hello!

Thanks for the feedback!


On Mon, Mar 12, 2007 at 04:09:25PM +0200, Constantine Kousoulos wrote:
> IMHO, o GSoC project should be something doable that can be 
> completed within the given time. Too broad tasks should be avoided.

Correct.  However, it's often difficult to estimate whether a task fits
into that categorization or not.

> Libchannel is a prerequisitive for many proposed projects. I think 
> that any project that depends on it, should not be proposed. IMHO, 
> each project should be independed of the others for maximum 
> efficiency.

Also correct.  However, if two people that are know to work together want
to work parallel to each other, say one on libchannel and the other on
pfinet, then that can only help as both of them then can help each other
and base their things on what the other one actually needs.  But of
course that'll only work for sufficiently skilled people.

> AFS? Ext2fs is not working at 100%. Ext3fs support is virtually 
> null. Ognyan Kulev worked on ext3fs, but all his work is 
> documented in bulgarian :(. Why bother with AFS?

Correct.  However, the Google Summer of Code is about writing code.
Tracing down bugs in ext2fs plus all the libraries -- finally even down
to Mach! -- is certainly needed, but can't be done as a GSoC project.
Likewise, someone having a look at Ognyan's ext3fs code and all the
journaling libraries he wrote / ported / extended would be a very welcome
thing to do, but is again not possible as a GSoC project.

> cthreads-->pthreads: From time to time the same question arises. 
> What is the status of pthread support? Does this task involve bug 
> fixing or code writing? From my limited experience i tend to think 
> it's more of the former, but then again i really don't know.

There are already patches for a number of libraries and translators to
convert them to pthreads, but it's not finished at all.  I don't think
that too much code-writing should be needed and it'll be more like
integrating everything and bug fixing and so on and given that, the
question again is whether it's then really suitable as a GSoC project.

> Glue code update: Finally something i have personal experience of. 
> I think it's too complex to be on GSoC. For more details, see one 
> of my old posts here 
> http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00076.html. 
> Linux has all the documention we need to write new glue code. 
> However, Mach has almost no documentation on how to write device 
> driver code. I believe this is a long term project that can only 
> be accomplished under the close guidance of an experienced mentor.

That may very well be true, yes.  However, if someone is already
experience in Linux or *BSD kernel code, it may be easier for her than it
was for you (not an expert in such code, if I remember correctly) when
you gave it a try.


Also note, that we don't have to accept people when they have applied for
a project.  If we -- upon having evaluated their application -- talk to
them and get to the understanding that they're not the right ones to do
the job, then there's no problem with instead prefering other people
working on other projects, within the GNU project's list of items.
(Remember that a fixed number of GSoC slots will be assigned to each
mentoring organization.)


If someone has further comments, then please post them quickly: I'll very
soon post the list of project I'm going to come up with to the GNU GSoC
administrators to have it oncluded in the GNU list of project; students
can begin applying to project tomorrow.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Constantine Kousoulos]

IMHO, o GSoC project should be something doable that can be 
completed within the given time. Too broad tasks should be avoided.


Libchannel is a prerequisitive for many proposed projects. I think 
that any project that depends on it, should not be proposed. IMHO, 
each project should be independed of the others for maximum 
efficiency.


AFS? Ext2fs is not working at 100%. Ext3fs support is virtually 
null. Ognyan Kulev worked on ext3fs, but all his work is 
documented in bulgarian :(. Why bother with AFS?


cthreads-->pthreads: From time to time the same question arises. 
What is the status of pthread support? Does this task involve bug 
fixing or code writing? From my limited experience i tend to think 
it's more of the former, but then again i really don't know.


Glue code update: Finally something i have personal experience of. 
I think it's too complex to be on GSoC. For more details, see one 
of my old posts here 
http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00076.html. 
Linux has all the documention we need to write new glue code. 
However, Mach has almost no documentation on how to write device 
driver code. I believe this is a long term project that can only 
be accomplished under the close guidance of an experienced mentor.


For the rest of the tasks, i agree with Thomas' comments or have 
the same questions.


Thanks,
Constantine


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Michael Banck]

Hi,

On Sun, Mar 11, 2007 at 08:44:00PM -0400, Barry deFreese wrote:
> Are we talking Debian specific stuff or no?  

This is about the FSF's GSoC project, so I don't think Debian-specific
stuff would be appropriate.

> There still the Debian installer afair.

Yes, but after last year's fiasco, I'm weary to waste another Debian
GSoC slot on Debian GNU/Hurd again, the port has enough PR problems in
Debian as is.

> Also, how about implementing PPP?

Some solution for DSL etc. wouldn't be bad, but today most people have
Ethernet of a dedicated DSL router I guess, so it's less urgent than a
couple of years ago I think.

> I think there was something about being able to boot from a stow'd
> filesystem?

That might be an important task for the GNU system, but AFAIK it's only
a matter of debugging/finding the culprit, not sure whether it merits a
GSoC project really.


Michael


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Barry deFreese]

Thomas Schwinge wrote:

Hello!

On Mon, Mar 05, 2007 at 01:14:30AM +0100, I wrote:
  

Like they did last year, Google is again hosting a Summer of Code program
in 2007.  See .

The GNU project is again going to apply for being a mentoring
organization and has asked the various GNU subproject to already begin
collecting ideas about projects being worth attending there.  See




  

Suitable tasks would again be made up from the ones already registered at
 and from the ones you are
going to send in now.



I began to make some thoughts about that; please comment.


http://savannah.gnu.org/task/?1619 -- designing and writing libchannel, a
library for streams

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5469 -- Rewrite pfinet

The libchannel project should be done before, or at least in parallel,
I'd say.


http://savannah.gnu.org/task/?5470 -- Implement pfinet6

The ``rewrite pfinet'' project should be done before (and libchannel
transitively), or at least in parallel, I'd say.


http://savannah.gnu.org/task/?5485 -- Design and implement a sound system

Both libchannel and the device driver update should be done before, or at
least in parallel, I'd say.


http://savannah.gnu.org/task/?5486 -- Andrew File System (AFS)

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5487 -- cthreads -> pthreads

How much is actually left to be done?  Consider that the GSoC is about
writing code, not about debugging.


http://savannah.gnu.org/task/?5488 -- Update the device driver glue code
in GNU Mach

Shall we publish that one as a project?


http://savannah.gnu.org/task/?5489 -- GNU Mach's IPC / VM system

This is most probably too complex for a GSoC project.


http://savannah.gnu.org/task/?5497 -- nfs and nfsd

Manuel Menal was working on that during the 2006 GSoC, but didn't get it
to an end.  His code is still available in the
`mmenal-soc2006-nfs-branch' branch.  Someone would have to check how much
work there is left to be done, to decide if we can put it up as a project
again.


http://savannah.gnu.org/task/?5499 -- Logical Volume Manager (LVM)

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5503 -- extended attributes

How much is actually left to be done?  Consider that a patch to add
support for reading and writing of extended attributes is already
available in .


http://savannah.gnu.org/task/?6231 -- Implement support for futexes

Is this a suitable project?


http://savannah.gnu.org/task/?6584 -- Improve Xen support

Is this a suitable project?


http://savannah.gnu.org/task/?6612 -- Overriding the system's default
servers

Is this a suitable project?


Further suggestions are of course still welcome!


Regards,
 Thomas
  
Are we talking Debian specific stuff or no?  There still the Debian 
installer afair.


Also, how about implementing PPP?

I think there was something about being able to boot from a stow'd 
filesystem?


Thanks!

Barry


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Google Summer of Code 2007

[Thomas Schwinge]

Hello!

On Mon, Mar 05, 2007 at 01:14:30AM +0100, I wrote:
> Like they did last year, Google is again hosting a Summer of Code program
> in 2007.  See .
> 
> The GNU project is again going to apply for being a mentoring
> organization and has asked the various GNU subproject to already begin
> collecting ideas about projects being worth attending there.  See
> 

> Suitable tasks would again be made up from the ones already registered at
>  and from the ones you are
> going to send in now.

I began to make some thoughts about that; please comment.


http://savannah.gnu.org/task/?1619 -- designing and writing libchannel, a
library for streams

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5469 -- Rewrite pfinet

The libchannel project should be done before, or at least in parallel,
I'd say.


http://savannah.gnu.org/task/?5470 -- Implement pfinet6

The ``rewrite pfinet'' project should be done before (and libchannel
transitively), or at least in parallel, I'd say.


http://savannah.gnu.org/task/?5485 -- Design and implement a sound system

Both libchannel and the device driver update should be done before, or at
least in parallel, I'd say.


http://savannah.gnu.org/task/?5486 -- Andrew File System (AFS)

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5487 -- cthreads -> pthreads

How much is actually left to be done?  Consider that the GSoC is about
writing code, not about debugging.


http://savannah.gnu.org/task/?5488 -- Update the device driver glue code
in GNU Mach

Shall we publish that one as a project?


http://savannah.gnu.org/task/?5489 -- GNU Mach's IPC / VM system

This is most probably too complex for a GSoC project.


http://savannah.gnu.org/task/?5497 -- nfs and nfsd

Manuel Menal was working on that during the 2006 GSoC, but didn't get it
to an end.  His code is still available in the
`mmenal-soc2006-nfs-branch' branch.  Someone would have to check how much
work there is left to be done, to decide if we can put it up as a project
again.


http://savannah.gnu.org/task/?5499 -- Logical Volume Manager (LVM)

This should be fine to put up as a project.


http://savannah.gnu.org/task/?5503 -- extended attributes

How much is actually left to be done?  Consider that a patch to add
support for reading and writing of extended attributes is already
available in .


http://savannah.gnu.org/task/?6231 -- Implement support for futexes

Is this a suitable project?


http://savannah.gnu.org/task/?6584 -- Improve Xen support

Is this a suitable project?


http://savannah.gnu.org/task/?6612 -- Overriding the system's default
servers

Is this a suitable project?


Further suggestions are of course still welcome!


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Google Summer of Code 2007

[Thomas Schwinge]

[Please follow up on  only; no need to be subscribed.]

Hello!

Like they did last year, Google is again hosting a Summer of Code program
in 2007.  See .

The GNU project is again going to apply for being a mentoring
organization and has asked the various GNU subproject to already begin
collecting ideas about projects being worth attending there.  See


Do we, the GNU Hurd project, want to participate in 2007?

A timeline is available at
 and condeses
to mentoring organizations having to apply this week and students having
to apply in two weeks.  Students will begin working on (and mentors begin
mentoring) their projects at the end of May and finish towards the end of
August.


I can already now estimate that I won't be able to invest a lot of time
into mentoring during that period (due to university study work).  I
nevertheless offer to again be a mentor this year.  What are other
potential mentor's comments?


Suitable tasks would again be made up from the ones already registered at
 and from the ones you are
going to send in now.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd