From owner-freebsd-hackers Wed Dec 22 20: 8:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 702AE14DB4 for ; Wed, 22 Dec 1999 20:08:48 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA10640; Wed, 22 Dec 1999 20:08:26 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kip Macy Cc: miaobo@mail.zhongxing.com, hackers@FreeBSD.ORG Subject: Re: Code In-reply-to: Your message of "Wed, 22 Dec 1999 17:14:20 PST." Date: Wed, 22 Dec 1999 20:08:26 -0800 Message-ID: <10636.945922106@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Typically it refers to moving a process and all its associated attributes > from one machine to another. There are a lot of problems with it, to > the best of my knowledge the only OS that ever managed to get it right was > Berkeley's Elf which was designed with it in mind from the beginning. > Osterhout, the professor heading the group, said afterwords that the costs > exceeded the gains. True enough, but that said, I also think that a lot has been lost in Unix by not having implemented processes as proper "first class objects". Instead, we have the pretense of centralized process information in the proc structure and the reality of lots and lots of process-specific information (outstanding resource requests, timers, etc) scattered all over the place. That means that to get your hands on all the truly useful information about a process and the resources it's using, you have to invent the often evil /proc abstraction or live with grubbing in /dev/kmem. Taking a more direct implementation approach in our process model is, I feel, what also led to the current model of the open file descriptor table, a primitive mechanism which isn't even close to being abstract enough to allow one to do the really neat stuff, like break or insert things into existing pipe streams, redirect the source or sink in a stream after it's been established, etc. Such abilities would seem to be an only natural extention to Unix's traditional "give an engineer a flexible set of tools" philosophy, and maybe if people had thought a bit more about process migration back when BSD was getting its start, we'd at least have some of the nifty abstractions and mechanisms which lead up to the ability to migrate processes if not the actual ability. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message