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
--

[ message continues ]

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
--

[ message continues ]

Hi Linus,


On Tue, Mar 4, 2008 at 9:35 PM, Linus Torvalds

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
--

[ message continues ]

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

[ message continues ]

On Tue, 4 Mar 2008 23:05:34 +0300

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

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
--

[ message continues ]

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
--

[ message continues ]

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. 
--

[ message continues ]

Hi all,


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
--

[ message continues ]

On Tue, 4 Mar 2008 21:55:14 +0200

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).


--

[ message continues ]

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
--

[ message continues ]

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 ...
[ message continues ]

Hi Sam,



["""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 ...
[ message continues ]

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

--

[ message continues ]

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.

--

[ message continues ]