From owner-freebsd-hackers Wed Jun 19 20:45:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4C68837B405 for ; Wed, 19 Jun 2002 20:45:35 -0700 (PDT) Received: from monica.cs.rpi.edu (monica.cs.rpi.edu [128.213.7.3]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA21709; Wed, 19 Jun 2002 23:45:32 -0400 (EDT) Received: from monica.cs.rpi.edu (crossd@localhost) by monica.cs.rpi.edu (8.11.6/8.11.6) with ESMTP id g5K3jXT14645; Wed, 19 Jun 2002 23:45:33 -0400 (EDT) (envelope-from crossd@monica.cs.rpi.edu) Message-Id: <200206200345.g5K3jXT14645@monica.cs.rpi.edu> To: Terry Lambert Cc: "David E. Cross" , hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: projects? In-Reply-To: Message from Terry Lambert of "Wed, 19 Jun 2002 19:25:26 PDT." <3D113D16.6D1A0238@mindspring.com> References: <200206200209.g5K297R14456@monica.cs.rpi.edu> <3D113D16.6D1A0238@mindspring.com> Date: Wed, 19 Jun 2002 23:45:33 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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 . 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