Date: Sat, 13 Jun 1998 22:10:39 -0700 From: Mike Smith <mike@smith.net.au> To: "Duncan, John" <jddst19@srg.psych.pitt.edu> Cc: "'Mike Smith'" <mike@smith.net.au>, "'freebsd-small@freebsd.org'" <freebsd-small@FreeBSD.ORG> Subject: Re: FreeBSD for PalmPilot/Palm III Message-ID: <199806140510.WAA03294@antipodes.cdrom.com> In-Reply-To: Your message of "Sat, 13 Jun 1998 20:50:10 EDT." <B57B47656446D111BDCE0060B01A8CAE05D12A@srg.psych.pitt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This has stopped being interesting, so I'll hope you'll forgive me for being succinct. I will summarise to begin with: If you really think that it can be done, and that you know everything that needs to be known about doing it, do it. I will personally buy a Palm III and make X run on it as soon as you do. > > 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 "demand-segmentation" is a non sequiter. > > 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. You run out of segment registers pretty fast though. > > 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? I don't know - tell me and I will. I'm simply trying to point out, as someone that seems to have a little more information than you, that you can't trivially pull FreeBSD's VM system out from under it and expect it to work, and you can't trivially reimplement the VM system on an architecture that doesn't cleave to the basic page/pagetable/page attributes model. > > 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. Naturally, code should run on any platform, even no platform at all. Everything should be implemented from first principles - you can't even assume the strong atomic force when writing truly "good" code. > > 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. And naturally the system has never evolved to use these features, or perhaps to depend upon them. You could just revert to all that V7 functionality which must still be there in the code, just perhaps commented out. Wait; V7 - isnt' that what Minix looks like? Perhaps you're agreeing with me. > > 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. Yes. Applicability to reality was the "afterthought" for Mach. > > 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? MachTen was the BSD emulator running on Mach. It required a PMMU in order to work adequately, let alone perform. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806140510.WAA03294>