Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!psinntp!psinntp!psinntp!spunky.RedBrick.COM!nntp.et.byu.edu!africa.nicoh.com!cwis.isu.edu!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD support [was Re: God Damn partition crap!]
Date: 29 Mar 1996 02:25:03 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 78
Message-ID: <4jfhlv$kt1@park.uvsc.edu>
References: <4hqav8$kmo@nntp.interaccess.com> <3140F2B6.41C67EA6@freebsd.org> <4i1qp4$bmj@nntp5.u.washington.edu> <4i50q6$64i@uriah.heep.sax.de> <4i727m$1hl@nntp5.u.washington.edu> <4j0mhb$r6i@calypso.bns.com.au> <31559EE7.59E2B600@FreeBSD.org> <4ja7fp$b6h@hole.sdsu.edu> <31595019.59E2B600@FreeBSD.org> <4jbvue$fdl@hole.sdsu.edu>
NNTP-Posting-Host: 198.17.250.210
larryr@saturn.sdsu.edu (Larry Riedel) wrote:
] My attitude is that if I give someone software, free or not, and parts
] of it are significantly more difficult to use than they would have been
] if they had documentation which a reasonable person would agree should
] have been there in the first place, then I am not doing anyone a favor
] by providing the missing information via tech support. In any case, to
] me it is not a question of whether or not that attitude is right or wrong,
] only the extent to which people will want use the software.
One can argue that, in the limit, all technical support falls
into the category "crisis management".
Which is to say that it is easier to put of until later that
which is not a crisis now.
There are well known process fixes that resolve these issues
in all cases; in general, they fall into the categories of
"commercial release managment" and "design before code".
] In the dozens of articles I have seen about adding a disk over the last
] year, for example, I have not noticed that those people are all "chronic
] compainers," but of course there will always be chronic complainers and
] that is a fact which has to be accepted. The more popularity a product
] has, the more chronic complainers there will be.
The problem with disks is that disk management is a
fundamentally hard problem.
When designing disk managemnt software, you must make a trade
between implementational complexity and complexity of use.
The fundamental problem is DOS. It is the very existance of
DOS which requires knowledge of disk geometry... specifically
BIOS disk geometry.
I can brief you in detail on what needs to be written to solve
the complexity problem, but be forewarned that the tasks are
not trivial. The three potential soloutions are:
1) VM86() support to allow INT 13 BIOS calls to be made
from a protected mode kernel.
2) A three stage boot process incompatible with the
PREP (IBM/Sun/Motorolla) OpenBoot or the proposed
MultiBoot (Intel) standards to allow a real mode
program to gather the data and pass it to the
protected mode kernel.
3) All disk setup to be done with a real mode program.
Clearly, option 3 is unacceptable.
With the BIOS geometry information available to the kernel,
it is possible to generalize and abstract the entire
parittioning process (in fact, I have a YACC and LEX
grammar that does precisely that, which I am willing to
give you -- it won't do you any good unless you tackle
problem #1 or #2 first... and they are hard problems).
With such a general tool in hand, it is possible to front
end the tool with an "idiot menu" or even a GUI, which will
communicate with the tool in order to implement a simplistic
user interface.
But the complexity must exist somewhere, whenever a complex
problem is to be solved. This is not an issue of "inadequate
support" or "inadequate documentation".
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.