Date: Wed, 19 Jun 2002 23:45:33 -0400 From: "David E. Cross" <crossd@cs.rpi.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: projects? Message-ID: <200206200345.g5K3jXT14645@monica.cs.rpi.edu> In-Reply-To: Message from Terry Lambert <tlambert2@mindspring.com> of "Wed, 19 Jun 2002 19:25:26 PDT." <3D113D16.6D1A0238@mindspring.com> References: <200206200209.g5K297R14456@monica.cs.rpi.edu> <3D113D16.6D1A0238@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Well, I mentioned it for 2 reasons. The first to demonstrate his background, and potential related areas that he might be interested in. The second was I think he could be convinced to do networking again if it was "intreesting", or could be made to seem interesting. So if you have ideas in this area, feel free to share ;) > 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. Exactly. This is why I brought it up. I personally have been bit by not being able to allocate large, unfragmented, blocks of physical RAM. I think this is potentially of the greatest benefit to the project, and the closest to VM work that is reasonable given the other criteria, but I don't see the data gathering aspects for him in this. Would it be possible that such a defragmentation could 'recolor' pages? Or are pages allocated with optimal colors already? One could gather data on cache performance at that point. > 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. This is the section of the kernel where I am the weakest by far, we would need substantial outside help for this. > 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. We have an intense interest in OpenAFS, and a license, but <see above>. Also it appears that OpenAFS is going along well on its own at this point. If this goes well for everyone, it could very easily be the start of many more such projects. Potentially on a continual basis. That is my real goal here. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD 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?200206200345.g5K3jXT14645>