From owner-freebsd-platforms Sun Dec 1 00:54:53 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA07175 for platforms-outgoing; Sun, 1 Dec 1996 00:54:53 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA07169 for ; Sun, 1 Dec 1996 00:54:49 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vU7fg-000QrTC; Sun, 1 Dec 96 09:54 MET Received: (grog@localhost) by freebie.lemis.de (8.8.3/8.6.12) id JAA02306; Sun, 1 Dec 1996 09:31:43 +0100 (MET) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Message-Id: <199612010831.JAA02306@freebie.lemis.de> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: <199611301740.JAA19857@GndRsh.aac.dev.com> from "Rodney W. Grimes" at "Nov 30, 96 09:40:47 am" To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Sun, 1 Dec 1996 09:31:42 +0100 (MET) Cc: platforms@FreeBSD.org, carr_richard@tandem.com, andyo@ora.com (Andy Oram) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Rodney W. Grimes writes: >>> >>> Of course, if I'm wrong and it's actually totally trivial, then I'll >>> just go sit in the corner and cry 8) Any chance of a pmap(9) manpage >>> detailing its features and requirements? 8) >>> >> PS, I FULLY intend to document the VM system. The more noise that >> is made about it, the higher priority it becomes. I am sure that >> if everyone said: I don't care about LFS for now, etc -- then I would be >> very willing to do the docs... Frankly, I am not in a programming >> mood right now, so it might not be a bad thing. >> >> Perhaps if DG and I produced more docs, then we could get more >> parallel efforts going. Actually, there are other kernel hackers >> that appear to be coming up to speed quite nicely (which is really >> a wonderful thing.) Maybe we can get the ball rolling!!! > > Have you ever tried to go buy a good book on VM system design? I seem > to remeber a day when David and myself where down at Powell technical > book store and he purchased one of the OSF manuals just because it had > a whole chapter on the VM system. Richard Carr (carr_richard@tandem.com) wrote one years ago. I suspect it's now completely out of date. > IMHO, a ``book'' written by one of the technical staff of O'Reiley with > John Dyson and David Greenman as the technical contributors would fill > a VERY LARGE void on many a persons technical library shelf/book case/ > library! Sadly, I think O'Reilly is the wrong choice now. They might have been the right choice a few years back, but they've all but turned their back on UNIX. Also, I think that a book on VM internals is rather more theoretical than the typical "hands-on" ORA book. I'm copying Andy Oram, my editor at ORA, to give him the chance to shout me down on either of those points--go for it, Andy. > I book sounds like a daunting task, but books often get created from smaller > documentation processes, and if we can get you two to write us 10 pages on > the pmap code, perhaps a technical writter can be recruited someplace to > grow this start into something larger. Even a 10 page paper would be > well recieved at many of the technical conferences, though I am not sure > how you feel about doing paper presentations :-). I'm certainly prepared to help on putting this together. Apart from anything else, I'll finally be forced to learn something about the internals. I'd suggest that we go for more than "the design of the FreeBSD 3.0 virtual memory system", though. Greg From owner-freebsd-platforms Sun Dec 1 02:55:55 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09994 for platforms-outgoing; Sun, 1 Dec 1996 02:55:55 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA09988 for ; Sun, 1 Dec 1996 02:55:53 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vU9Yr-000QrIC; Sun, 1 Dec 96 11:55 MET Received: (grog@localhost) by freebie.lemis.de (8.8.3/8.6.12) id KAA14349; Sun, 1 Dec 1996 10:11:30 +0100 (MET) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Message-Id: <199612010911.KAA14349@freebie.lemis.de> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: from Warner Losh at "Nov 29, 96 09:40:39 pm" To: imp@village.org (Warner Losh) Date: Sun, 1 Dec 1996 10:11:29 +0100 (MET) Cc: platforms@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh writes: > Are there people other than myself that are interested in getting FreeBSD > running on MIPS machines? They made a bunch of different ones: DECstations, > ARC BIOS PCs, SGI boxes, old pre SGI-MIPS hardware, Sony's NEWS and likely > a dozen others that I've not been able to recall. I have an ARC BIOS MIPS > PC that I'd love to have FreeBSD running on, but don't really want to do > the MIPS port by myself. Anybody else out there with disk space to burn, > and old MIPS hardware? Oh, why not? If I can get my Control Data Cyber 910 (a personal IRIS disguised in grey) running with some other disk, I'd have a hack at it. Greg From owner-freebsd-platforms Sun Dec 1 03:30:25 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA10836 for platforms-outgoing; Sun, 1 Dec 1996 03:30:25 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA10823; Sun, 1 Dec 1996 03:30:12 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vUA62-000QrIC; Sun, 1 Dec 96 12:30 MET Received: (grog@localhost) by freebie.lemis.de (8.8.3/8.6.12) id MAA04186; Sun, 1 Dec 1996 12:29:29 +0100 (MET) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Message-Id: <199612011129.MAA04186@freebie.lemis.de> Subject: Re: FreeBSD/MIPS anybody In-Reply-To: <544.849436642@critter.tfs.com> from Poul-Henning Kamp at "Dec 1, 96 11:37:22 am" To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Sun, 1 Dec 1996 12:29:28 +0100 (MET) Cc: FreeBSD-current@FreeBSD.org (FreeBSD current users), platforms@FreeBSD.org (FreeBSD Platforms), doc@FreeBSD.org (FreeBSD Documenters), committers@FreeBSD.org Reply-To: doc@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk (Following up to -doc; this isn't really a -current, -committers, or -platforms issue) Poul-Henning Kamp writes: > In message <199612010831.JAA02306@freebie.lemis.de>, Greg Lehey writes: >> >>> Discussion about a FreeBSD book documenting the internals of VM] >> >> I'm certainly prepared to help on putting this together. Apart from >> anything else, I'll finally be forced to learn something about the >> internals. I'd suggest that we go for more than "the design of the >> FreeBSD 3.0 virtual memory system", though. > > I think I'd like to pull the brake here. I don't see any advantage to > a book over a bunch of SGML/nroff/tex files in the src/share/doc tree. There is the advantage that more people would look at the book if it were there. I think there's a significant inertia which people need to overcome before they print out the papers, and I'd guess that the sources in /src/share/doc don't get formatted too often. But I don't know if the advantage of the book would outweigh its disadvantages, such as getting the thing printed in the first place, the high price you'd have to charge for a relatively low-volume book, and the fact that it would be eternally out of date. > The only possible difference would be some money from the sale of the > book, and quite frankly, I would not even put that in budget for a book of > this kind. It certainly doesn't promise to be a big money-maker. > Instead I'd far rather have us find a volounteer editor and maybe a couple > of writers, who would help make english out of the stuff the kernel hackers > emit, which is, all else being equal, usually closer to C than to any dialect > of English. > > If we manage to pull sufficient material together this way, we can take it > all to some publisher and say, "Here, bunch of Postscript files, call the > book ``FreeBSD -- Under the hood'' and send our money to the FreeBSD project." > > If on the other hand we don't get sufficiently material, which is unfortunately > entirely possible, then we will not have to argue with some editor about it, > but it will be available in the tree, to anybody who want to read it or improve > it. > > This is also far more in line with the "scientific spirit" that was the > foundation of the BSD code on whose shoulders we stand. All this sounds very sensible. > So in summary: If you have something you're good at, or just the only one > who knows something about, you should really sit down and crank some text > out. > > Don't worry about formatting, language or anything like that right > now, just crank out some ASCII file and commit it somewhere not entirely > wrong under src/share/doc. > > Come on guys! > > Documentation is the other 50% of the job! OK. I volunteer to integrate and polish the texts. I've just been leafing through the 4.4BSD kernel book. How about taking something like that as a framework in which to put the documentation, rather like the way the online handbook is structured at the moment? Also, does anybody have more documents stashed away just waiting for publication? > Poul-Henning > Author of the only new paper in share/doc/papers from the FreeBSD project :-( I suppose it says something that I had to go and look for this document. Greg From owner-freebsd-platforms Sun Dec 1 15:42:23 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06833 for platforms-outgoing; Sun, 1 Dec 1996 15:42:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA06826; Sun, 1 Dec 1996 15:42:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09228; Sun, 1 Dec 1996 16:23:22 -0700 From: Terry Lambert Message-Id: <199612012323.QAA09228@phaeton.artisoft.com> Subject: Re: FreeBSD/MIPS anybody To: toor@dyson.iquest.net (John S. Dyson) Date: Sun, 1 Dec 1996 16:23:22 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, imp@village.org, platforms@freebsd.org, dyson@freebsd.org In-Reply-To: <199611300612.BAA09955@dyson.iquest.net> from "John S. Dyson" at Nov 30, 96 01:12:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I do think that problems with previous port attempts > are due to a lack of understanding of how the code works. The code > is subtile^2. > > There are some X86 optimizations, but those are implemented mostly > in the pmap code. Those routines should be noops on architectures > like R4000, where they have software managed TLB's. We don't really > need the reference bit, and our performance will degrade under heavy > load without it. But, NO OS is going to do as well without that bit. Is there any way you can seperate the consumer interface code from the implementation interface code? Specifically, I'd like to see some abstract objects, and documentation (I'm willing to help out writing it, but as John points out, the VM system is, to a large degree, a black box) such as: ======================================================================= ... 4.0.0 Porting This section describes the necessary steps for porting the VM services to other architectures. ... 4.1.0 Prerequisites Each architecture that will support the VM system will need to support the following logical abstractions: ... ... ... 4.1.1 Functional abstraction The VM system is abstracted by ... . This allows the use of a layered "pseudo-VM" to hide architectural crudities from the user of the VM system (for example, the VFS). An example of this might be the abstractions necessary to support SMP on Intel processors. Any dependencies here should be hidden below the VM so that upper level code will not have to change when the underlying architecture is changed. Restated, this means the the VM functional abstraction is a very important part of the FreeBSD HAL (Hardware Abstration Layer). 4.2.0 A porting example To port the VM system to the Motorolla PPC603 (as used in the Apple PowerMac, Motorolla Ultra, Arrow Electronics OEM, FirePower OEM, and BeBOX), the following functions will need to be defined: ... ... ... 4.2.1 Emulating hardware function in software Because the PPC603 does not support ..., the following will need to be emulated in software: ... ... ... To do this, we can rely on the ... feature of the PPC to trigger pseudo-events when the following conditions occur: ... ... ... The upper layer code does not distinguish between events (real events) and emulated events resulting from software detection (pseudo events). Remember back in section 3.1.2 where we discussed emulation of the write protect bit when copying data from user space to kernel space, and section 3.1.4 where we discussed emulation of a write protect that works in kernel mode for kernel-kernel copying, for all Intel processors. ... ... ... ... 4.3.5 L1 and L2 Cache interaction and MP In section 4.3.3, we introduced the idea of page coloring. Some architectures, however, can not support MP an an L2 cache simultaneously. A specific example is the BeBox, which replaces the L2 cache with the second processor. This is because it can not support distributed cache coherency -- it simply does not have the necessary pins to notify the processor of a cache event. The discussion of MESI noted the situations in which SMP interactions can cause conditions requiring intervention, and how these events can be generated in hardware, or how they may be emulated as pseudo-events, so that cache coherency can be maintained across several processors. Our example port, the PPC 603, can not support this. Instead, an SMP design for the PPC603 can handle processor coherency requests as L2 cache coherency requests. This means that you can't have an L2 cache at the same time you support more than one processor. We intentionally picked the PPC 603 as our example, not only because of its use of soft page structures and how they must be emulated in software, but because there is an existing PPC 603 implementation of SMP using L2 cache replacement. This implementation is the BeBox. Remember how MESI works... clearly, the L2 cache can not initiate events as if it were a processor... it's not an equal citizin. In particular, out of "MESI", it can't support "S" ... "Shared". Instead, the BeBox uses an MEI (Modified Exclusive Invalid) architecture. This means some changes for the VM system. Consider the following: ... ... ... ... ======================================================================= Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-platforms Sun Dec 1 15:42:39 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06852 for platforms-outgoing; Sun, 1 Dec 1996 15:42:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA06847 for ; Sun, 1 Dec 1996 15:42:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09254; Sun, 1 Dec 1996 16:24:50 -0700 From: Terry Lambert Message-Id: <199612012324.QAA09254@phaeton.artisoft.com> Subject: Re: FreeBSD/MIPS anybody To: imp@village.org (Warner Losh) Date: Sun, 1 Dec 1996 16:24:50 -0700 (MST) Cc: platforms@freebsd.org In-Reply-To: from "Warner Losh" at Nov 29, 96 09:40:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-platforms@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Are there people other than myself that are interested in getting FreeBSD > running on MIPS machines? They made a bunch of different ones: DECstations, > ARC BIOS PCs, SGI boxes, old pre SGI-MIPS hardware, Sony's NEWS and likely > a dozen others that I've not been able to recall. I have an ARC BIOS MIPS > PC that I'd love to have FreeBSD running on, but don't really want to do > the MIPS port by myself. Anybody else out there with disk space to burn, > and old MIPS hardware? I am interested... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-platforms Tue Dec 3 12:06:37 1996 Return-Path: owner-platforms Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08416 for platforms-outgoing; Tue, 3 Dec 1996 12:06:37 -0800 (PST) Received: from ruby.ora.com (ruby.ora.com [198.112.208.25]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA08410 for ; Tue, 3 Dec 1996 12:06:35 -0800 (PST) Received: from pc102.ora.com (pc102.ora.com [198.112.208.102]) by ruby.ora.com (8.6.13/8.6.11) with SMTP id PAA18971; Tue, 3 Dec 1996 15:05:54 -0500 Date: Tue, 3 Dec 1996 15:05:54 -0500 Message-Id: <199612032005.PAA18971@ruby.ora.com> X-Sender: andyo@ora.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Greg Lehey , rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) From: Andy Oram Subject: Re: FreeBSD/MIPS anybody Cc: platforms@FreeBSD.org, carr_richard@tandem.com Sender: owner-platforms@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I don't think it's fair to say we've "turned our back," but we're not guarding UNIX with an ever-turning sword either. To be less abstract about it, we're doing fewer books about UNIX and more books about NT and cross-platform stuff (Web, Java) than we did several years ago. That's partly because the industry is (unfortunately) moving away from UNIX, and partly because we've done a good job on UNIX and there aren't as many new topics there as before. I don't mind at all people knowing that we're doing other books, but please, we don't plan to abandon UNIX at all. I'm doing your debugging book, after all. I'm working on another couple Linux books, and I'm considering a couple other projects in the UNIX arena. But I don't expect to get huge returns for doing these things. Our The virtual memory idea does sound too academic and not practical enough for our series. UNIX is one thing, BSD is another. I'm personally not sure how much we should have supported BSD. The message I kept getting from my superiors here (as you proposed various projects) was that BSD was no longer a big enough market. The suddenly our German subsidiary decided to publish a BSD-specific book. I think my managers were disappointed at poor sales of the official BSD4.4 manual set; they didn't realize we might have been able to make a god product with something that was our own material. Andy