Date: Wed, 19 Jun 2002 19:25:26 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: hackers@freebsd.org Subject: Re: projects? Message-ID: <3D113D16.6D1A0238@mindspring.com> References: <200206200209.g5K297R14456@monica.cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"David E. Cross" wrote: > I have a graduate student who cam to me about a masters project involving > some work with FreeBSD. He has currently zero knowledge of the Kernel, and > is looking to change that, but he needs ideas. His previous areas of > interest are primarily focused on networking; RED/GRED/ECN, routing, etc. > He is however "quite sick" of networking, and was originally looking at > the VM code as a potential area (he is gaining an interest in > parallelization and synchronization). I suggested this may be too > ambitious for someone with zero previous exposure to the kernel (what > do others think?) As alternate projects I suggested: > > Memory Compaction: compacting physical memory, maintaining coloring > VFS: nullfs, unionfs, etc... > OpenAFS: Speaks for itself. Too bad he's sick of networking. There a lot of intersting code that could be implemented in the main line FreeBSD that would be really beneficial, overall. The memory compaction is an intersting problem, but might require some really serious changes, since you could not compact anything that was in the compaction code path. Reclaiming large sections of kernel memory (basically defragging it) would help those people who want to build camera and other drivers that need to call for a contigmalloc, and which are expected to be loaded potentially well after boot time. A similar set of changes would be necessary to handle kernel paging (basically, it breaks down into section attributes to allow or to disallow paging of code/data in specific ELF sections). I would say, though, that they were two seperate projects (but the second one would leverage the first to greater benefit). Most of the VFS stuff is really VM stuff. An interesting VFS project would be to create a pseudo-device that would proxy VOP requests to/from user space, so that you could develop stacking layers in user space. THis would also very quickly and concisely identify where things in the current VFS/VM interaction make assumptions that they ought not to be making. The OpenAFS code is not very interesting, to me. However, if you have an AFS license there, then your location is probably one of the few places the work could be done, so my preferences not withstanding, as long as you have a real AFS to run against for testing, then the OpenAFS could be a good project that could happen nowhere else. > What do people here think? Anyone have other ideas that I can forward on? > He is eager to work with others and seek guidance; some of which I can > provide (how much depends on the project of course ;). > > (He is looking to spend 2 hours a day for roughly 6 months on this project; > ideally he would want a project where he can gather data on the results, most > of my projects do not fall into that category). I hesistate to mention this; you would have to see if the University of Guelph is working on it already. But... how about an NFSv4 implementation for FreeBSD? At 2 hours a day for 6 months, you are talking 260 man hours, approximately, or the equivalent of 1/8th of a year... 1.5 man months. So whatever project that's picked will have to fit in that wrapper. If the 2 hours a day includes the data analysis and writeup, then you are probably talking about half that time for the actual project work. This is almost too little to take on most kernel projects, if it's not in an area that you're already familiar with, like networking, in this students case. I don't know if it would be considered "worthy", but a project to document CAM, NewBus, etc. ...device driver related FreeBSD internals... would also be really welcomed by a lot of people. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D113D16.6D1A0238>