Date: Sat, 6 Jan 2001 17:10:47 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: jasone@FreeBSD.org Cc: cluster@FreeBSD.org Subject: Decomposition of "process" -- will it be possible to have unbacked procs? Message-ID: <Pine.NEB.3.96L.1010106170308.19327F-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Jason, As part of your scheduler activation work, I know that you're looking at decomposing the concept of a "process", which will mean (among other things) improving abstractions for operations on processes. An idea that I am interested in is having process entries appear without a real local process (address space, etc) to back it. The process will instead reflect the status and condition of a process on a remote machine, probably managed by some sort of userland daemon. The daemon would update kernel information for the process entry, and when certain types of operations were performed on the process (signal delivery in particular), those operations would be forwarded to the supporting process to actually be delivered. Rght now, such a construction is not really possible, as there is a lot of code that assumes a process is "real" -- that is, each struct proc (other than zombies and nascent processes during creation) have a real address space, etc. While there are some abstractions to support changing the "nature" of a process (primarily used for emulation), I don't think they're currently sufficient to support what I'm describing. In effect, what I'd like to see is an abstracted kobj-like interface for actions performed on processes, so that alternative implementations could be provided. It seems to me that if such a mechanism were to be introduced, it would be nice to do it as part of the decomposition work -- identifying points where struct proc's are manipulated (scheduled, signal'd, debugged, status retrieved, killed gratuitously due to VM shortage, etc) and abstracting them now. As such, you could imagine two starting "process" implementations: the current-day model, and a scheduler activation model. Then you could imagine a kernel module being loaded to service a new "cluster process", backed by a daemon that propagated information and requests around. Any thoughts on the feasibility and/or usefulness of this? It's sort of Mach-esque. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-cluster" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010106170308.19327F-100000>