"The kernel newbies community often gets inquiries from CS students who need a project for their studies and would like to do something with the Linux kernel, but would also like their code to be useful to the community afterwards," explained Rik van Riel in a posting titled "WANTED: kernel projects for CS students". He offered a link to a Kernel Newbies wiki page titled "KernelProjects" adding, "if you have ideas on what projects would be useful, please add them to this page (or email me)". Rik explained that he was assembling a list of projects on that page that meet the following criteria:
"Are self contained enough that the students can implement the project by themselves, since that is often a university requirement; are self contained enough that Linux could merge the code (maybe with additional changes) after the student has been working on it for a few months; are large enough to qualify as a student project, luckily there is flexibility here since we get inquiries for anything from 6 week projects to 6 month projects."
From: Rik van Riel
Subject: WANTED: kernel projects for CS students
Date: Oct 14, 4:01 pm 2007
The kernel newbies community often gets inquiries from CS students who
need a project for their studies and would like to do something with
the Linux kernel, but would also like their code to be useful to the
community afterwards.
In order to make it easier for them, I am trying to put together a
page with projects that:
- Are self contained enough that the students can implement the
project by themselves, since that is often a university requirement.
- Are self contained enough that Linux could merge the code (maybe
with additional changes) after the student has been working on it
for a few months.
- Are large enough to qualify as a student project, luckily there is
flexibility here since we get inquiries for anything from 6 week
projects to 6 month projects.
If you have ideas on what projects would be useful, please add them
to this page (or email me):
http://kernelnewbies.org/KernelProjects
thanks,
Rik
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Develop the framebuffer
Develop the framebuffer driver of nvidia and ati-driver so that they provide 3D functionality for DirectFB or similiar projects.
Make a DirectX driver for Linux.
no way
nvidia/ati fb or especially directx is not something a single student could do by himself or in 6 months time.
that involves a lot of reverse engineering (fb driver) or a lot of legally dangerous actions (using ms documentation off msdn and not getting tainted by its licenses).
"Make a DirectX driver for
"Make a DirectX driver for Linux."
What's that got to do with the kernel?
Hmm
Port ZFS to Linux. Even if not moved to mainline, people could still download it, patch the kernel, compile and enjoy ZFS. :)
Make open source device driver for some hardware, eg. SoundBlaster X-Fi.
Or they could mow your
Or they could mow your lawn..?
A file versioning plugin to an existing filesystem
OK, there are several different versioning filesystems, but what I'm looking for is a version that closely resembles the file versioning provided by OpenVMS. Some may think that it's way too simple, some complains about that it clogs your hard drive etc, but then they are missing the point.
The versioning shall be on file level, and optionally on directory, but the latter isn't needed. Some existing solutions like ext3cow has a snapshot functionality, which isn't really necessary either. The simpler the better. One extra command will have to be implemented, and that's the "purge" command that can allow users to drop all but the N latest versions of a file. And there is no need for the full ODS-5 functionality of indexed files.
A few points:
The point behind this is to allow for keeping track of mainly configuration files, which tends to be tweaked over time. More complex versioning of files isn't needed and are best supported through CVS, SVN or any other version control system.
The point behind this is to
Why can't you keep your configuration files in a proper revision control system? CVS and SVN are obviously bad examples because they force you to set up a static repository somewhere and don't provide a lot of headroom.
But try distributed ones, they let you create a repository anywhere with a single command, without forcing you to think twice.
Automagic tracking
The point behind the OPs request is (as I understand it) automatic tracking of changes to config files. There are lots of tools out there that modify config files, and having to manually commit new changes defeats the "simple" requirement, IMO.
On the other hand, I think putting this into the kernel is not necessary at all. It seems to me you could very easily come up with a little userspace tool that used inotify to learn about changes to monitored files and automatically commits new versions of them to an SCM; even something as simple as the venerable RCS would be good enough for this IMO. A bit of graphical tooling on top to allow for quick browsing of diffs and reverting of versions and you'd have yourself a very sweet little system admin applet!
How about a FUSE versioned filesystem
Have you tried, for example, copyfs?
http://n0x.org/copyfs/
FUSE for / ??
The OP mentioned the reason for wanting this was to track changes to system files. System files (for the most part) live in /. I don't know if it's possible to use a FUSE filesystem as your / partition (it sounds impossible to me) but even if it were, I wouldn't be comfortable with it. Even just using /etc and other common directories for system config files would make me too nervouse.
Not /
Well, you probably could use it as root with an initrd image to mount it first. But this is probably not required. Most configuration files are stored /etc, as you say. Whether you would trust it... I wouldn't without a lot of testing. However the good thing about a fuse file system like this is that the code is typically much simpler than a real file system, as it's layered on an existing, tested, filesystem, like ext3. It's probably easier to make a correct versioning file system rather than writing one from scratch.
No!
The VMS versioning system was never intended to be used as anything like a historical archive system. It was only ever meant as a simple interim backup system to guard against accidental changes to files--nothing more long-term than that. Otherwise it wouldn't have been made so easy to lose all your past versions with the "purge" command (which users were encouraged to invoke regularly).
LVM boot
Boot from LVM partition :) like HPUX
Who cares? A proper /boot
Who cares? A proper /boot sits in it's own partition anyway.
I would like this as well
I would like this as well.
Too accustomed to AIX and spoiled by it.
Time to get rid off this legacy PC partitioning scheme.
Another wish is: add mirroring to the LVM level, to allow mirror creation for separate logical volumes. And implement volume migration through mirroring - would be a nice code refactoring. AIX, HPUX, Solaris all are good at that.