From mboxrd@z Thu Jan 1 00:00:00 1970 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] fs kernel: eagle MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-nejbmsfatfobvzzrvnltniqsya" Message-Id: <20001109070058.17E9D199E3@mail.cse.psu.edu> Date: Thu, 9 Nov 2000 02:00:56 -0500 Topicbox-Message-UUID: 24cc1f46-eac9-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-nejbmsfatfobvzzrvnltniqsya Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit it's worse than you know, some drivers are used in 5 different operating systems, all requiring them to be mangled to fit, it's a maintenance headache i'm well aware of. after saying so for years, i have actually started on merging the kernels. but don't hold your breath, there are lots of things to get in the way. --upas-nejbmsfatfobvzzrvnltniqsya Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Nov 8 04:34:40 EST 2000 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Nov 8 04:34:40 EST 2000 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7FE2D199EE; Wed, 8 Nov 2000 04:34:18 -0500 (EST) Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2986D199E3 for <9fans@cse.psu.edu>; Wed, 8 Nov 2000 04:33:09 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 13tRS4-0001KM-00 for 9fans@cse.psu.edu; Wed, 08 Nov 2000 09:23:28 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu From: Jakub Jermar Message-ID: <8u9s02$gtf$1@news.vol.cz> Organization: Video On Line References: <20001107153158.01B89199E1@mail.cse.psu.edu> Subject: Re: [9fans] fs kernel: eagle Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0rc1 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the O/S Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 8 Nov 2000 09:22:57 GMT > I suppose I could remove them, I remove the dregs of other dead hardware > when I find them. Hands up, who knows what this typedef in fs/port/portdat.h > was for: > typedef struct Bit Bit; > If you know, I pity you. I don't know what purpose was 'typedef struct Bit Bit' for -- I guess I was only ten or so when Plan 9 used to be proud of the SGI Power multiprocessor servers... But now I see that things like the Bit typedef, Eagle and Jaguar drivers merely ARE and their one and only task is silent being in the kernel. No doubts they should go. Besides these fossils, there is another thing that I would like to point out. Both fs and CPUterm kernels suffer mutual duplication of code. I've done a private survey on this issue in both kernels and found the following simillarities/duplicities: all kinds of locks pieces of scheduler including sleep() and wakeup() clock and time planning interrupt dispatching PCI, CGA, keyboard, floppy ethernets (etherlnk3, 82557, 2114x), ethernet generic interface scsi (NCR53c8xx), scsi generic interface IP protocols... ...and possibly many more. The result of my survey brought me to thoughts like: "let's have only one Plan 9 kernel". For there are only kernel processes in the fs kernel and all of them cooperate in the algorithm described in the File Server paper written by Ken Thompson, it should be no problem to transfer the functionality of it to the CPUterm kernel -- CPUterm kernel supports kernel processes, and all the hardware that fs kernel needs + more. With some #ifdefined'ing and a little (more or less) coding, we could achieve the fully functional fileserver kernel from the CPUterm source. One would be able to build different images from one source, depending on whether he wanted to build a file server or a CPUterm server kernel . (I also believe that there could be a slight distinction between kernels intended for CPU servers and kernels meant for terminals. While enterprise CPU servers are probably not going to need devices like VGA and sound, they should be given the opportunity to be free of them, terminals, on the other hand, might need some of the multimedia drivers. The scheduler could also be optimised for compute-bound processes on CPU kernels and for transput-bound processes on term kernels.) Well, what do you think? Jakub Jermar --upas-nejbmsfatfobvzzrvnltniqsya--