On Wed, Jan 29, 2003 at 10:00:18AM -0600, Tom Hart wrote: > W.r.t. programs with translators, of course, this (superior) style of > programming couldn't come about at present, since people would still > want APT to work on systems based on Linux and *BSD kernels. Something > I've been thinking is, I don't see how translators are inseperably tied > to multi-servers. Couldn't a Linux or *BSD kernel be hacked to support > translators?
It certainly could be, of course. Traditions Unix design doesn't allow the end user to easily change kernel tables. After you overcome that, your kernel would just have to refer to the table to see if there was an active translator associated with the inode and pass the calls to it. But that only really helps for filesystem translators. The other magic in translators is that most traditional syscalls are turned into RPCs and sent to various translators. With a bit of black magic, the user can replace those translators with his or her own for doing system development work, or other specialised hacking and do so without compromising the integrity of the system - Nothing is running with any greater priviledges that the user naturally has. Even this could probably be done with a bunch of work in the kernel and glibc, though. The Hurd was designed from the ground up with these ideas, though. Grafting them onto a traditional Unix design would be non-trivial. Tks, Jeff Bailey _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
