Google's Summer of Code?

Google's Summer of Code?

[Pekka Enberg]

Hi all,

Are there any plans to send an application of Linux kernel as a mentor
organization for Google's Summer of Code this year? I think there are
probably a lot of students interested in hacking on the kernel. And
no, I am not volunteering to send that application but I would be
interested in being a mentor.

			Pekka

Re: Google's Summer of Code?

[Linus Torvalds]

On Tue, 4 Mar 2008, Pekka Enberg wrote:
>
> Are there any plans to send an application of Linux kernel as a mentor
> organization for Google's Summer of Code this year? I think there are
> probably a lot of students interested in hacking on the kernel. And
> no, I am not volunteering to send that application but I would be
> interested in being a mentor.

We haven't done it before (afaik), and I don't think we've had anybody 
sign up to suggest a project and mentor it. It's probably worth talking to 
people in other projects that have done the gsoc thing before. 

And no, I'm not going to do that "mentor organization" application thing 
either, but there's bound to be *somebody* who wants to do it. Maybe it 
could even be done as part of the Linux-foundation drive (currently LSB 
and OpenPrinting, no kernel projects). See

	https://www.linux-foundation.org/en/Google_Summer_of_Code

and maybe we can add a kernel thing to there.

		Linus

Re: Google's Summer of Code?

[Pekka Enberg]

Hi Linus,

On Tue, 4 Mar 2008, Pekka Enberg wrote:
>  > Are there any plans to send an application of Linux kernel as a mentor
>  > organization for Google's Summer of Code this year? I think there are
>  > probably a lot of students interested in hacking on the kernel. And
>  > no, I am not volunteering to send that application but I would be
>  > interested in being a mentor.

On Tue, Mar 4, 2008 at 9:35 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>  We haven't done it before (afaik), and I don't think we've had anybody
>  sign up to suggest a project and mentor it. It's probably worth talking to
>  people in other projects that have done the gsoc thing before.
>
>  And no, I'm not going to do that "mentor organization" application thing
>  either, but there's bound to be *somebody* who wants to do it. Maybe it
>  could even be done as part of the Linux-foundation drive (currently LSB
>  and OpenPrinting, no kernel projects). See
>
>         https://www.linux-foundation.org/en/Google_Summer_of_Code
>
>  and maybe we can add a kernel thing to there.

Well, to that particular someone out there, please let me know where
to sign up as a mentor. I am also wondering if such a high profile
project as the kernel can get away with not having a "project ideas"
list which would make things real easy for the administrator(s)...

                                 Pekka

Re: Google's Summer of Code?

[Alexey Zaytsev]

On Tue, Mar 4, 2008 at 10:55 PM, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Linus,
>
>
>  On Tue, 4 Mar 2008, Pekka Enberg wrote:
>  >  > Are there any plans to send an application of Linux kernel as a mentor
>  >  > organization for Google's Summer of Code this year? I think there are
>  >  > probably a lot of students interested in hacking on the kernel. And
>  >  > no, I am not volunteering to send that application but I would be
>  >  > interested in being a mentor.
>
>
> On Tue, Mar 4, 2008 at 9:35 PM, Linus Torvalds
>  <torvalds@linux-foundation.org> wrote:
>  >  We haven't done it before (afaik), and I don't think we've had anybody
>  >  sign up to suggest a project and mentor it. It's probably worth talking to
>  >  people in other projects that have done the gsoc thing before.
>  >
>  >  And no, I'm not going to do that "mentor organization" application thing
>  >  either, but there's bound to be *somebody* who wants to do it. Maybe it
>  >  could even be done as part of the Linux-foundation drive (currently LSB
>  >  and OpenPrinting, no kernel projects). See
>  >
>  >         https://www.linux-foundation.org/en/Google_Summer_of_Code
>  >
>  >  and maybe we can add a kernel thing to there.
>
>  Well, to that particular someone out there, please let me know where
>  to sign up as a mentor. I am also wondering if such a high profile
>  project as the kernel can get away with not having a "project ideas"
>  list which would make things real easy for the administrator(s)...
>
>                                  Pekka
>

Maybe the Kernelnewbies should stand up as the mentoring organisation?

Re: Google's Summer of Code?

[Rik van Riel]

On Tue, 4 Mar 2008 23:05:34 +0300
"Alexey Zaytsev" <alexey.zaytsev@gmail.com> wrote:
> On Tue, Mar 4, 2008 at 10:55 PM, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> >  On Tue, 4 Mar 2008, Pekka Enberg wrote:
> >  >  > Are there any plans to send an application of Linux kernel as a mentor
> >  >  > organization for Google's Summer of Code this year? I think there are
> >  >  > probably a lot of students interested in hacking on the kernel. And
> >  >  > no, I am not volunteering to send that application but I would be
> >  >  > interested in being a mentor.
> >
> >
> > On Tue, Mar 4, 2008 at 9:35 PM, Linus Torvalds
> >  <torvalds@linux-foundation.org> wrote:
> >  >  We haven't done it before (afaik), and I don't think we've had anybody
> >  >  sign up to suggest a project and mentor it. It's probably worth talking to
> >  >  people in other projects that have done the gsoc thing before.

Actually, I have a list of possible projects online already:

http://kernelnewbies.org/KernelProjects

The list is on a wiki and "unfiltered", so we may need to look into the
quality of the proposals a bit more before Summer of Code, and/or accept
proposals by the Summer of Code volunteers and help them make sure their
proposals are useful.

> Maybe the Kernelnewbies should stand up as the mentoring organisation?

Kernelnewbies is just a community of people, without much organization.

However, I would be happy to coordinate a group of mentors for Linux
kernel Summer of Code as well as be a mentor for the kernel subsystems
that I know something about.

If we can find mentors to cover most of the kernel (volunteers? anyone?),
we can do a good enough job of mentoring the students that we could sign
up for Summer of Code.

Summer of Code could also be a good way to get some kernel related work
done, for example LTP tests for kernel subsystems that do not have a
test suite yet.  Maybe not the most interesting work, but it can be very
educational as well as useful - that and $5000 may be enough to motivate
students to get some of this "boring work" done :)

-- 
All Rights Reversed

Re: Google's Summer of Code?

[Giacomo A. Catenazzi]

Rik van Riel wrote:
> On Tue, 4 Mar 2008 23:05:34 +0300
> "Alexey Zaytsev" <alexey.zaytsev@gmail.com> wrote:
>> Maybe the Kernelnewbies should stand up as the mentoring organisation?
> 
> Kernelnewbies is just a community of people, without much organization.
> 
> However, I would be happy to coordinate a group of mentors for Linux
> kernel Summer of Code as well as be a mentor for the kernel subsystems
> that I know something about.
> 
> If we can find mentors to cover most of the kernel (volunteers? anyone?),
> we can do a good enough job of mentoring the students that we could sign
> up for Summer of Code.
> 
> Summer of Code could also be a good way to get some kernel related work
> done, for example LTP tests for kernel subsystems that do not have a
> test suite yet.  Maybe not the most interesting work, but it can be very
> educational as well as useful - that and $5000 may be enough to motivate
> students to get some of this "boring work" done :)

I propose and I could mentor two projects about automagical kernel
configuration:

- add support to menuconfig, to show what you should enable (not
really an automagical configuration, but more an helper which
know better(?) your hardware).
- new ideas about hardware/protocol detection and detection heuristics.

I've already done some parts: generating an hardware->kernel driver
database ( http://cateee.net/lkddb/ ), and a working prototype of
autoconfiguration ( http://testing.cateee.net/autokernconf/ ).

I really want to have new ideas and other developers. I think the
idea are appealing to students, and it doesn't requires a lot of
knowledge of kernel internal.

ciao
	cate

Re: Google's Summer of Code?

[Romano Giannetti]

On Wed, 2008-03-05 at 14:57 +0100, Giacomo A. Catenazzi wrote:
> - add support to menuconfig, to show what you should enable (not
> really an automagical configuration, but more an helper which
> know better(?) your hardware).

Yes, this would be a tool worth Infinite Distinction for a lot of Linux
users. Say I have a new laptop and I want to configure the kernel build
based on a) the (probably similar to allmodconfig) distribution .config,
and b) the set of loaded modules. It should be possible to dig into
Kconfig files and output a first-shot .config, which will save to
potential testers of new kernels hours of compilation and/or trimming 
down `grep CONFIG .config | wc -l` (2267) configuration options.

Thanks for proposing the idea.

Romano 


-- 
Sorry for the disclaimer --- ¡I cannot stop it!



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: Google's Summer of Code?

[Pekka Enberg]

Hi all,

On Tue, Mar 4, 2008 at 10:23 PM, Rik van Riel <riel@redhat.com> wrote:
>  Kernelnewbies is just a community of people, without much organization.
>
>  However, I would be happy to coordinate a group of mentors for Linux
>  kernel Summer of Code as well as be a mentor for the kernel subsystems
>  that I know something about.
>
>  If we can find mentors to cover most of the kernel (volunteers? anyone?),
>  we can do a good enough job of mentoring the students that we could sign
>  up for Summer of Code.

Ok, so we're planning to participate via Linux Foundation. You can add
your project ideas here:

https://www.linux-foundation.org/en/Google_Summer_of_Code

And sign up as a volunteering mentor here:

http://kernelnewbies.org/GoogleSummerOfCodeMentors

                                Pekka

Re: Google's Summer of Code?

[Andrew Morton]

On Tue, 4 Mar 2008 21:55:14 +0200
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> I am also wondering if such a high profile
> project as the kernel can get away with not having a "project ideas"
> list which would make things real easy for the administrator(s)...

http://kernelnewbies.org/KernelProjects

There are surely many more things we could put there.

I receive a dribble of emails about the setrlimit64/getrlimit64 one, so
people are looking at it, and are looking to do work.  (I haven't usefully
responded to those emails, btw - am not sure how my name got on that one -
probably Ulrich would be better).

Re: Google's Summer of Code?

[Andi Kleen]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 4 Mar 2008 21:55:14 +0200
> "Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
>
>> I am also wondering if such a high profile
>> project as the kernel can get away with not having a "project ideas"
>> list which would make things real easy for the administrator(s)...
>
> http://kernelnewbies.org/KernelProjects
>
> There are surely many more things we could put there.
>
> I receive a dribble of emails about the setrlimit64/getrlimit64 one, so
> people are looking at it, and are looking to do work.  (I haven't usefully
> responded to those emails, btw - am not sure how my name got on that one -
> probably Ulrich would be better).

http://marc.info/?l=linux-kernel&m=119981029708530&w=2

is also a candidate. There are still quite a lot of unconverted 
drivers over.

-Andi

text processing (Re: Google's Summer of Code?)

[Oleg Verych]

Andi Kleen @ Tue, 04 Mar 2008 21:38:46 +0100:
> Andrew Morton
[]
>> http://kernelnewbies.org/KernelProjects
>>
>> There are surely many more things we could put there.
>>
>> I receive a dribble of emails about the setrlimit64/getrlimit64 one, so
>> people are looking at it, and are looking to do work.  (I haven't usefully
>> responded to those emails, btw - am not sure how my name got on that one -
>> probably Ulrich would be better).
>
> http://marc.info/?l=linux-kernel&m=119981029708530&w=2
>
> is also a candidate. There are still quite a lot of unconverted 
> drivers over.

And you've saw first patch there...



I'd say, that i see similar things here (LKML, kernel), wrt shell usage
and text processing.

* checkpatch instead of hard-armed editors (*The* tools of programmers),
  with one's (linux, glibc, bash, whatever) source-friendly capabilities
  (error/coding-style highlight, easy call-graph, param checking, security
   audit(+audit scripts), etc.)

* linux-2.6/scripts/unifdef.c instead of coding style + simple script
  (reinventing of compilers is a dream of CS professors of all times :)

* much of te `make` based stuff

* text processing, which is source code processing, if we are in
  Open Source, has no place in
  + design (super-macro constructs --> C code),
  + auditing (stupid vmsplice() case *and* first ``fix'')
  + testing (writing source in parallel with constructing userspace
    test programs, based on same source; once all is done, script
    generates/constructs kernel part)

* and perl is everywhere


On my `sed` scripts i was getting (from Sam):

   "Because your shell script is unreadable by normal human beings[*]
   while the perl script for people with a bit of perl fu can read it
   and fix/modify it.

   We want tools that can be maintained and enhanced by most people.

   [*] Normal human beings are people with same level of shell
   scripting/sed skills that I have just to put that straight."

   "Linecount is down but so is maintainability / extendability."

So, no tools or perl is better than nothing?

I don't say, i will solve Andi's quest, i just lost interest. But it is
damn interesting one! One, that many script kiddies will do in minutes,
if they would knew `sed` and a bit of UNIX practice, but not perl, C,
diff, git, etc.

So, teach youngsters about "maintainability / extendability" and "Normal
human beings", or what? OTOH, Who are teachers?

Just two points to show skill mismatch, i.e. for

+ managing/manipulating source,
+ designing, writing, maintaining correct kernel code.

Latter isn't for n00bs, right?

* multi-line grep
    Andi Kleen http://mid.gmane.org/20080109000358.GF2117@one.firstfloor.org

* full and correct greping of linux style function definitions
    Linus Torvalds http://mid.gmane.org/1054519757.161606@palladium.transmeta.com

All in one shot:

# print linux-style function definitions

sed -n '
/^[^[:blank:]#/].*[),]$/{
 /,$/{
 :_start;
   N;
   s=)$=&= ; t_end ; b_start;
 :_end;
 };
p}' kernel/*c | pager

#_____

One may not know `sed` at all (but i glad to explain and share
everything, i know), *patterns* and expressions are key things.

Once you have approved and try-and-buy tested one, everything else is
pure technical thing. Maybe somebody outstanding (like Rusty) can do that
with CPP, i don't know; `sed` is just more familiar thing for this.

Silence in reply i will understand quite right, i might be wrong. I just
can't see all that stuff not having much skilled people
involved/interested.
--
-o--=O`C
 #oo'L O
<___=E M

kernelprojects::menuconfig [was:Re: Google's Summer of Code?]

[Jan Engelhardt]

Hi Sam,


On Mar 4 2008 12:13, Andrew Morton wrote:
>"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
>
>> I am also wondering if such a high profile
>> project as the kernel can get away with not having a "project ideas"
>> list which would make things real easy for the administrator(s)...
>
>http://kernelnewbies.org/KernelProjects
>

["""Update menuconfig to a modern ncurses look & feel

htop, aptitude, tig and other ncurses based programs has a more modern 
and effective look&feel than current menuconfig. Rip out all the 
lxdialog stuff and replace it with a ncurses based frontend that looks 
better and has more functionality."""]


I remember the last discussion about it, and I am still kinda in the 
position of "really?". I find the current menuconfig interface 
perfectable suitable.

I could not relate how menuconfig should look htop-style, because htop, 
for the most use, is just one screen with a process overview and a 
rather spartan "menu", should one decide to change some configuration 
options. Essentially it is a 4-column expand-to-the-right menu. No idea 
how to put it better.

aptitude. I only seen it very briefly since I do not use Debian. I can 
probably say the package selection in the OpenSolaris initial installer 
is similar, in other words, _all_ CONFIG options are listed in 
tree-style fashion in one window...

	> [ ] feature1
	  [ ] . . . feature2
	  [ ] . . . feature3
        > [ ] feature99

something like that. Anyway, I dislike the tree (expandable and 
contractable at will at the > points) — menuconfig seems superior
since, after entering a new submenu, just the options inside it are
displayed and nothing around it.

Then there are splitscreen approaches like qconfig/xconfig do, 
and I think I would not like that either for menuconfig; moving between 
two panels (one: the menu selection as a tree, the other: options for 
this submenu) is, kinda confusing in a text environment.

Of course there is a plus point for the tree-in-one (aptitude) approach 
in that searching for options/features is easier. The current menuconfig 
has a limited search function, for example, it will not take you to the 
option you searched but return to the menu you started the search from. 
Which means you have to repeatedly search for the option because you 
cannot remember the menus you have to go through to reach the option.

My stance: remain with the current menuconfig, and improve on the 
search(-and-jump) function.

Awaiting your counter-arguments and -opinions please.


thanks,
Jan

Re: kernelprojects::menuconfig [was:Re: Google's Summer of Code?]

[Willy Tarreau]

On Tue, Mar 04, 2008 at 10:44:39PM +0100, Jan Engelhardt wrote:
> Hi Sam,
> 
> 
> On Mar 4 2008 12:13, Andrew Morton wrote:
> >"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:
> >
> >> I am also wondering if such a high profile
> >> project as the kernel can get away with not having a "project ideas"
> >> list which would make things real easy for the administrator(s)...
> >
> >http://kernelnewbies.org/KernelProjects
> >
> 
> ["""Update menuconfig to a modern ncurses look & feel
> 
> htop, aptitude, tig and other ncurses based programs has a more modern 
> and effective look&feel than current menuconfig. Rip out all the 
> lxdialog stuff and replace it with a ncurses based frontend that looks 
> better and has more functionality."""]
> 
> 
> I remember the last discussion about it, and I am still kinda in the 
> position of "really?". I find the current menuconfig interface 
> perfectable suitable.
> 
> I could not relate how menuconfig should look htop-style, because htop, 
> for the most use, is just one screen with a process overview and a 
> rather spartan "menu", should one decide to change some configuration 
> options. Essentially it is a 4-column expand-to-the-right menu. No idea 
> how to put it better.
> 
> aptitude. I only seen it very briefly since I do not use Debian. I can 
> probably say the package selection in the OpenSolaris initial installer 
> is similar, in other words, _all_ CONFIG options are listed in 
> tree-style fashion in one window...
> 
> 	> [ ] feature1
> 	  [ ] . . . feature2
> 	  [ ] . . . feature3
>         > [ ] feature99
> 
> something like that. Anyway, I dislike the tree (expandable and 
> contractable at will at the > points) ??? menuconfig seems superior
> since, after entering a new submenu, just the options inside it are
> displayed and nothing around it.
> 
> Then there are splitscreen approaches like qconfig/xconfig do, 
> and I think I would not like that either for menuconfig; moving between 
> two panels (one: the menu selection as a tree, the other: options for 
> this submenu) is, kinda confusing in a text environment.
> 
> Of course there is a plus point for the tree-in-one (aptitude) approach 
> in that searching for options/features is easier. The current menuconfig 
> has a limited search function, for example, it will not take you to the 
> option you searched but return to the menu you started the search from. 
> Which means you have to repeatedly search for the option because you 
> cannot remember the menus you have to go through to reach the option.
> 
> My stance: remain with the current menuconfig, and improve on the 
> search(-and-jump) function.
> 
> Awaiting your counter-arguments and -opinions please.

100% agreed with you Jan, menuconfig is excellent. I was even thinking
that it would be really cool if someone could extract Kbuild from the
kernel and produce an independant framework to make it easier to include
in other projects. I would really like to be able to launch a "make
menuconfig" or "make oldconfig" with my own softs, and see only what
has changed being rebuilt. Think about all the people who get nervous
when "./configure" does not produce what they want...

Another project I was thinking about is a "smart" patch utility. Right
now, "patch" works line by line. While this may be understandable for
"patch", it's pretty annoying to see the same behaviour in "merge".
Why not have a smarter pair of tools which would be able to detect
changes in consecutive lines, or even merge changes on the same line ?
merge cannot even merge two changes on consecutive makefile entries
right now, which has an impact on git's ability to merge changes.
For instance, as an exercise to teach git to a friend, I used the
following file :

a=1
b=1
c=1

Then, branch b changes b=1 to b=2, and branch c, c=1 to c=2. You cannot
merge them automatically, which is a shame. So there is room for improvement
here :-)

Regards,
Willy

Re: Google's Summer of Code?

[Avi Kivity]

Pekka Enberg wrote:
> Hi all,
>
> Are there any plans to send an application of Linux kernel as a mentor
> organization for Google's Summer of Code this year? I think there are
> probably a lot of students interested in hacking on the kernel. And
> no, I am not volunteering to send that application but I would be
> interested in being a mentor.
>   

kvm will apply, and though some of the work will be in userspace, we'd 
like to have kernel contributions as well.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: Google's Summer of Code?

[Casey Schaufler]

----- Original Message ----
> From: Avi Kivity <avi@qumranet.com>
> To: Pekka Enberg <penberg@cs.helsinki.fi>
> Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>; Andrew Morton <akpm@linux-foundation.org>; Linus Torvalds <torvalds@linux-foundation.org>; Ingo Molnar <mingo@elte.hu>; Vegard Nossum <vegard.nossum@gmail.com>
> Sent: Tuesday, March 4, 2008 12:51:00 PM
> Subject: Re: Google's Summer of Code?
> 
> Pekka Enberg wrote:
> > Hi all,
> >
> > Are there any plans to send an application of Linux kernel as a mentor
> > organization for Google's Summer of Code this year? I think there are
> > probably a lot of students interested in hacking on the kernel. And
> > no, I am not volunteering to send that application but I would be
> > interested in being a mentor.
> > 
> 
> kvm will apply, and though some of the work will be in userspace, we'd 
> like to have kernel contributions as well.

As will Smack, the mandatory access control model of the future,
 
Casey Schaufler
casey@schaufler-ca.com 

Re: Google's Summer of Code?

[Avi Kivity]

Casey Schaufler wrote:
>
>> kvm will apply, and though some of the work will be in userspace, we'd 
>> like to have kernel contributions as well.
>>     
>
> As will Smack, the mandatory access control model of the future,
>   

I need to take marketing lessons.  "kvm, the most scalable and flexible 
virtual machine monitor, will apply etc."


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.