Date: Fri, 16 Feb 2007 23:53:54 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, Joel Dahl <joel@FreeBSD.org> Subject: Re: cvs commit: www/en/projects/ideas index.sgml Message-ID: <20070216234810.M73842@fledge.watson.org> In-Reply-To: <20070216172621.GA80812@xor.obsecurity.org> References: <200702161712.l1GHCX81057433@repoman.freebsd.org> <20070216172621.GA80812@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Feb 2007, Kris Kennaway wrote: > On Fri, Feb 16, 2007 at 05:12:33PM +0000, Joel Dahl wrote: >> joel 2007-02-16 17:12:32 UTC >> >> FreeBSD doc repository >> >> Modified files: >> en/projects/ideas index.sgml >> Log: >> Spring cleaning in preparation for Google SoC 2007. Remove the following >> projects (based on discussions with netchild and rwatson): > >> - FPU subsystem overhaul: Not suitable as a Google SoC project. >> - Process Checkpointing: Not suitable as a Google SoC project. > > Is this a "Google SoC projects list" or a "FreeBSD projects list"? IMO just > because something is not an appropriate SoC project doesn't mean it's not > suitable for someone more advanced to take on. The FPU subsystem overhaul port has already been done by Attilio and is available as patches, I believe, and basically requires evaluation at this point. That evaluation might be an appropriate project for someone to work on (although not for SoC). I don't mind seeing process checkpointing on an overall project idea list, but I think we should replace the text there with something substantially more informative. There's a significant research literature on how you do these sorts of things and I'm not sure we want to ask people to hack it up without figuring out what it is we actually want out of such a project. Otherwise, patches for something we don't want will turn up and leave disappointment all around. In particular, there are countless reasons why simply implementing "checkpointing" of processes in isolation is relatively meaningless, and if required, probably best done with involvement of the application rather than transparently in the OS. In a clustered/distributed system, checkpointing provided by the OS is a far more meaningful concept. If we're serious about wanting checkpointing, let's have a session at the developer summit at BSDCan on what it is we want and why, have a couple of people read into the research literature here, and re-add a checkpointing project once we have something a bit more directed to put up. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070216234810.M73842>