From owner-freebsd-small Sat Jun 13 17:40:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA28768 for freebsd-small-outgoing; Sat, 13 Jun 1998 17:40:41 -0700 (PDT) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from post-ofc06.srv.cis.pitt.edu (root@post-ofc06.srv.cis.pitt.edu [136.142.185.43]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA28760 for ; Sat, 13 Jun 1998 17:40:31 -0700 (PDT) (envelope-from jddst19@srg.psych.pitt.edu) Received: from srg.psych.pitt.edu (srg.psych.pitt.edu [136.142.64.27]) by post-ofc06.srv.cis.pitt.edu with ESMTP (8.8.8/8.8.8/cispo-7.2.2.2) ID for ; Sat, 13 Jun 1998 20:40:30 -0400 (EDT) Received: by srg.psych.pitt.edu with Internet Mail Service (5.0.1457.3) id ; Sat, 13 Jun 1998 20:50:12 -0400 Message-ID: From: "Duncan, John" To: "'Mike Smith'" , "'freebsd-small@freebsd.org'" Subject: RE: FreeBSD for PalmPilot/Palm III Date: Sat, 13 Jun 1998 20:50:10 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id RAA28761 Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Mike Smith [SMTP:mike@smith.net.au] > Sent: Saturday, June 13, 1998 7:05 PM > To: Duncan, John > Subject: Re: FreeBSD for PalmPilot/Palm III > > I presume this was meant to be a reply... > > > > The version of "Linux" that runs on the Pilot has no VM. Unlike > > > Linux, > > > where the VM is still more or less an afterthought, FreeBSD lives > and > > > breathes through the VM system. > > > > > > Motorola's Dragonball (the CPU in the Pilot) has no PMMU, so no > VM. > > > > > > [-- ] Yes, it has no PMMU. It does have support for segmented > memory. > > > The Macintosh used segmented memory extensively. What is lacking > on > > > the Dragonball is memory protection hardware. What is notable > about > > > segmented memory is that it is possible to do the protection in > > > software. > > > (OS2 1.0) This is not desirable with paging. > > It's not a question of memory protection, but rather demand-related > activities, and the ability for one piece of physical memory to appear > in several locations in a disjoint fashion. You can't do this > equivalen > tly with segmentation. > > [-- ] Demand-segmentation models have been around at least as long > as demand-paging models. Segmentation, though, views memory with > larger chunks and different attributes. This means that the memory > model > doesn't translate identically from a paged system to a segmented > system, > but it doesn't rule them out... Segmented systems can, in fact, share > memory with differing addresses. This is especially possible when > there > is a large address space and very little physical memory. > > > > There is little reason why VM can't be done with segmentation. > There > > > is > > > also little reason why VM is entirely necessary in a machine with > no > > > swap. > > Here you make it clear that you didn't grasp the importance if what I > said above - FreeBSD lives and breathes through the VM system. VM is > not something "just for swap"; it's critical for almost everything > involving communications between the kernel and userspace, not to > mention interprocess communications and the filesystem. > > [-- ] Why do you have to attack my knowledge of computer science? > Most > operating systems require their memory systems; and some require > features > in their memory systems to be available. I wouldn't disagree with > anyone who > insisted that FreeBSD is an advanced operating system. > > VM is, essentially, a product of a memory model that allows > non-existant > addresses to function. This is usually for swap, but it also has other > purposes. > One can have a paged or a segmented address space that provides all of > the features of protected memory; and the protection does not have to > occur > in hardware. This just makes it faster. VM is not shared memory, it is > not > protected memory. VM is virtual memory. We look at a virtual memory > model > as one that provides protection mechanisms and uses them in such a way > that memory does not have to be in the same place. It is possible, and > feasible, > to segment memory such that one can reference memory he does not > own, and such that the operating system can move memory where it wants > it. Certain features are interesting to embedded systems. Certain > others are > not. In a slow machine with never more than one user, why would it be > desirable > to provide a full-featured memory model? It wouldn't. To provide a > compatible > one would be a good move. > > If code requires certain memory structures to be available, then it is > probably > bad code, or platform-specific code. How could a program be a good one > if, > for example, it required 4k pages? What would happen if someone were > to > run the thing on a different machine? Writing too much code like that > can only > cripple an OS's utility on other platforms. > > The major limitation to a segmented memory model is the loss of a flat > address space. I don't think that most programs people intend to run > on a little > palm-pilot would beg for more than the avg. segment size anyway. If > they do, > then I'd worry about the programmers who wrote the code. > > Even so, using demand-segmentation it is still possible to assign > different- > sized segments to a requestor. Provided that code does not rely on a > pointer > being in the same place after a realloc(), the code should work on > either a > paged or segmented model. > > > > The resultant system cannot be called FreeBSD, but it can look > very > > > similar. > > > Honestly, the core features of FreeBSD are the system calls and > the > > > unix-like interface to everything. Many other things are > > > afterthoughts; if not > > > to FreeBSD, they are afterthoughts to 4.4Lite, 3.0BSD, or V7, > > > somewhere > > > along the line. > > This puts the hypotheis that BSD has not changed fundamentally since > v7, which is a major error. > > [-- ] You failed to grasp my point. UN*X as it is now is one big > afterthought. The system was created as a quick and dirty testbed > for Dennis Ritchie's programs. Then it became a little operating > system used internally on DEC machines at Bell Labs. Through > modification after modification, the thing became the behemoth that > it is now. Even though Linux's VM system is obviously an afterthought > compared to Minix's lack of one, FreeBSD's VM is only an extension > of BSD's VM which was an afterthought to Bell's lack thereof. > > If you'd like a look at a system that was designed from the ground up > to have advanced features like VM, IPC, etc, then look at Mach. Unix's > fs and drivers are the afterthought to Mach's microkernel. > > For an interesting experiment into the necessity of even VM on an > operating system you should look at SPIN, which has VM included > as an extension, and OSF's kernel interface as an extension as well. > This doesn't mean that SPIN doesn't have a memory model, but the > VM is included separately for a number of reasons. > > If you seriously want to put an alternative operating system on a > Pilot, I would go looking at Minix, which is designed to work (and > work > well) on small, non-VM systems. It's now freely available for > downloading, and is not a bad place to start if you're porting for the > > first time. > > [-- ] Perhaps, but why not a larger and more usable system? Minix is > extremely limited. MachTen implemented 4.3BSD that ran on a 68k > without > memory hardware. What was so special about their system that couldn't > be done with FreeBSD? > > > > > We could also go into versions for WindowsCE machines. After > all, > > > who > > > > really wants WindowsCE? It's junk. What could be really cool > would > > > be to > > > > create a FreeBSD EEPROM for some of those CE machines and let > people > > > > replace it. > > > > > > Most CE machines are too short-lifed and closed architecture-wise > to > > > be > > > worth porting to. By the time you'd worked out how they were laid > > > out, > > > the few of the model you had still in existence would be in the > bottom > > > > > > of 10-year-old kids' sock drawers. 8( > > > > > > [-- ] Yes. But there must be a kernel of WCE machines with nicer > > > vendors. Why not look into it? > > There must? What makes you think this? And what makes you think that > > I haven't already looked into it? > > The core issue is that there is no such thing as "a WinCE machine". > WinCE is relatively portable, and each vendor buys a source license > and > then ports it to their own platform. In many cases, the production > version of this platform lacks the basic support for new OS > development. > > > > OTOH, for less than twice the cost of a Palm-III you can buy an > > > easily-overclockable Toshiba Libretto 50, which runs FreeBSD, has > a > > > 640x480 colour screen, a keyboard and takes honkin' big disks. > > > > > > [-- ] Doesn't fit into my shirt pocket. I tried.:) > > Put it in your jacket. You won't fit a Palm III and a Ricochet in > your > pocket either, so the point is somewhat moot. 8) > > -John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message