From owner-freebsd-cluster Sat Jan 6 14:10:50 2001 From owner-freebsd-cluster@FreeBSD.ORG Sat Jan 6 14:10:48 2001 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 412A437B400; Sat, 6 Jan 2001 14:10:48 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f06MAl720242; Sat, 6 Jan 2001 17:10:47 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 6 Jan 2001 17:10:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: jasone@FreeBSD.org Cc: cluster@FreeBSD.org Subject: Decomposition of "process" -- will it be possible to have unbacked procs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: robert@fledge.watson.org Sender: owner-freebsd-cluster@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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