Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.com!imci4!newsfeed.internetmci.com!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX)
Date: Mon, 15 Apr 1996 23:10:46 -0700
Organization: Me
Lines: 104
Message-ID: <317339E6.581CCB0B@lambert.org>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu> <4krsc4$m7t@taco.cc.ncsu.edu>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21402 comp.unix.bsd.386bsd.misc:598 comp.unix.bsd.bsdi.misc:3208 comp.unix.bsd.netbsd.misc:3018 comp.unix.bsd.freebsd.misc:17367 comp.os.linux.advocacy:45526
Kevin P. Neal wrote:
]
] Ummm, Lesstif has a long way to go, but if it did get "there" one day,
] things will be alot nicer. We need more people.
If you are a legal conservative (ie: you err on the side of
caution), then Lesstif is very dangerous.
It's dangerous because of the LGPL relink restriction and data
vs. text linkage in current "state of the art" shared library
technologies (as is any LGPL library until and unless the LGPL
takes specific notice of shared library technology in the
relink clause).
It's also dangerous because of the derivation of some of the
interfaces: people "peeking" at header files (which is possible,
if expensive, to defend against) and namelist dumps of real
Motif libraries (which is much less defensible: unlike header
files constituting "published documentation", object file symbols
have never been tested in a US court, as far as I know).
Lesstif is far from "clean room" standards in these regards.
] We just had half of this discussion on the NetBSD mailing lists.
] The only thing that I suggested that didn't get cut to pieces
] (glad I can say "student" as an excuse, just kidding) was that
] perhaps having the DDX layer be dld'd into the Xserver would be
] a better idea.
]
] That way, the server stays modular, the kernel stays small, the
] Xfree guys do the work, the kernel guys keep their hands in the
] kernel proper, and we have a collection of .o files to distribute
] instead of entire binaries. It also keeps the server source from
] diverging when different people start working on different cards.
] Just use the common server, and write a new ddx.
Two words: state recovery
Two more words: kernel debugger
Because the X server makes modifications to the hardware settings
of which the kernel can not be aware without the server having to
go through the kernel to make them, it is a requirement that mode
save and switch operate by signals to the X server.
In the case of state recovery, like the "instant install" I was
discussing in this thread, and more generally, full-on power
management capability for full system checkpoint-restart, the
applciation is not up at the time that state must be recovered,
and so can not possibly respond to signals.
In the case of the kernel debugger, if you panic or intentioanlly
drop to the kernel debugger (breakpoint, etc.) for the purposes
of debugging (for instance) console code/X server interaction,
then the kernel is not actively running the X process. Therefore,
the X process can not handle the signal, and therefore can not
put the console in a state usable to the kernel debugger.
At the very least, it is desirable to implement what Amancio
Hasty suggested nearly two years ago: an interpreter in kernel
space for use in console mode setting and recovery. Thus the
X server must give the console driver the magic incantation
required to set and recover the desired modes.
This is less useful if you pull in two more words: other programs
X is not the only program that may want low level video services.
There's DOS emulation, DOS emulation in a virtual console (like
the "MS-DOS Prompt" Windows in Windows 95), and other applciations,
like those that want to use the Linux VGALIB or AT&T's MGR
interface.
Leaving the state recovery code in user space isn't very
satisfactory.
] Uh, so what's to stop somebody (except time) from getting ahold of the
] specs to MAPI, et al, and hacking a mail program or something or other
] to provide the API at the C program level?
Good taste. 8-).
MAPI is an API at the wrong conceptual level. It was a bad example
for Jordan to use in the first place.
] Hmmmm, where do I get these specs, anyway?
ftp.micorsoft.com, or Microsoft LeveL II developer program
(~$500/year), from which you get the Windows95/NT SDK and DDK,
which include documentation on this, Plug-N-Play implementation,
and other such arcane-to-UNIX-minds topics.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers