From owner-freebsd-hackers Tue Jun 30 20:00:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05810 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 20:00:08 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05794 for ; Tue, 30 Jun 1998 19:59:48 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id TAA11708 for ; Tue, 30 Jun 1998 19:59:24 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: hackers@FreeBSD.ORG Subject: Anyone interested in an "interesting" project idea? Date: Tue, 30 Jun 1998 19:59:24 -0700 Message-ID: <11704.899261964@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is something that DG and I were talking about for awhile on the phone last night and agreed that it would be a nice feature if one were also *very careful* to note that this was neither a replacement or substitute for actual clustering, just one piece of the clustering universe (ala VMS more than "PVM" and friends) brought into FreeBSD for administrative convenience. Right, that disclaimer aside, the basic (and very half-baked, based on a single conversation :) concept. First, you change pid_t from an integer to something like this: typedef struct _pid_t { u_int hostid : 8; u_int pid : 24; } pid_t; So that for any given pid, you can find out if it's running on your machine (hostid = 0) or is really somewhere else. Then you add some extra smarts to the kernel* to do hostid to network ID translation (an IP address for now, I guess) and also teach it the notion of a cluster group, basically some list of hosts which are said to share the same "cluster identifier." When some operation is carried out against a foreign pid, like signal delivery, the kernel would be responsible for mapping the hostid to an actual IP address and doing an RPC for the remote operation with the user credentials and such being passed along. Needless to say, such machines would also have to trust one another. :-) The cluster naming issues would come up with reporting commands like ps - if you want ps to show the processes running on every node in your cluster, for example, you need to have some notion (somewhere) of which hosts comprise it so that `ps -axC' will generate a nice list of processes for only your home cluster. You also probably want to be able to do things like `ps -axC admin' to get a ps for all the hosts in the `admin' cluster, or allow the default cluster to be overridden in the environment. Note that, again, this is *not* anything like actual clustering even though I'm using that word. It's more like an "administrative unit" paradigm where you can do any process operations for any machine in the unit from any other machine. Just think of the possibilities: "*click* Hey Joe, did you know some crackers are into your systems? They have 40 eggdrops running on every single one of your 29 shell machines! Heh.." "Dammit! Is that true?! Hang on!" # ps -axC shell-group | grep egg # killall -9 -C shell-group eggdrop And isn't that a lot easier than the alternative? :-) Sure, one can always cobble together kludges which do essentially the same thing, but it's a real pain compared to simply teaching the system how to allow process administration to be more group oriented - one of those features, as DG put it, that you wonder how you ever lived without once you've had it. I also said `kernel*' earlier since there's some possibility that you could do a lot of the translation and lookup stuff in usermode, it wouldn't have to be in the kernel. You could even strip the extra hostid information off the pid_t's in the relevant syscall wrappers (kill(), wait(), etc) and do the RPC before the kernel even gets its hands on the pid, going for minimal change, but some aspects of this might end up needing to be stuffed into the kernel anyway for other reasons - it's hard to say without getting more seriously stuck into the problem. Anyway, people are always clamoring for project ideas and saying that we in core don't share enough of our wishlist items with folks, so here I am. Any volunteers? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message