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
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
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
<[email protected]> 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
On Tue, Mar 4, 2008 at 10:55 PM, Pekka Enberg <[email protected]> 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
> <[email protected]> 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?
On Tue, 4 Mar 2008 21:55:14 +0200
"Pekka Enberg" <[email protected]> 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).
On Tue, 4 Mar 2008 23:05:34 +0300
"Alexey Zaytsev" <[email protected]> wrote:
> On Tue, Mar 4, 2008 at 10:55 PM, Pekka Enberg <[email protected]> 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
> > <[email protected]> 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
Andrew Morton <[email protected]> writes:
> On Tue, 4 Mar 2008 21:55:14 +0200
> "Pekka Enberg" <[email protected]> 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
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.
----- Original Message ----
> From: Avi Kivity <[email protected]>
> To: Pekka Enberg <[email protected]>
> Cc: Linux kernel mailing list <[email protected]>; Andrew Morton <[email protected]>; Linus Torvalds <[email protected]>; Ingo Molnar <[email protected]>; Vegard Nossum <[email protected]>
> 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
[email protected]
Hi Sam,
On Mar 4 2008 12:13, Andrew Morton wrote:
>"Pekka Enberg" <[email protected]> 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
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/[email protected]
* full and correct greping of linux style function definitions
Linus Torvalds http://mid.gmane.org/[email protected]
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
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" <[email protected]> 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
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.
Rik van Riel wrote:
> On Tue, 4 Mar 2008 23:05:34 +0300
> "Alexey Zaytsev" <[email protected]> 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
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.
Hi all,
On Tue, Mar 4, 2008 at 10:23 PM, Rik van Riel <[email protected]> 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