Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: The patchkit (was Re: Excessive Interrupt Latencies)
Message-ID: <1993Mar22.071652.16937@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1obts0$doq@hal.gnu.ai.mit.edu> <1993Mar21.014401.2911@fcom.cc.utah.edu> <1oh26m$qtb@hal.gnu.ai.mit.edu>
Date: Mon, 22 Mar 93 07:16:52 GMT
Lines: 159
First of all, sorry to Charles for Nuking him for his last post; I had just
come back from a really rough day brought on by a similar design criticism
not nearly as well founded as Charles', and I was out of order
In article <1oh26m$qtb@hal.gnu.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>You are seriously confused. You seem to think that patching order is
>an important problem, when in practice, it's pretty simple to have the
>patchkit check the order and issue errors or even offer to
>automatically install previous patches.
I don't think it's an important problem (in that it's easily resolved), I
think it's an important *issue* in the design of any replacement. I am
not suggesting that a pissy little shell script (that's what "patches" is,
even though I've had people assume otherwise and request "source code") is
the end-all, be-all of revision control, and in fact agree that a replacement
is necessary and inevitable.
>Of course, CVS (RCS) pretty much automates this, albeit it in a bit
>different manner.
I dislike this for one of the reasons I dislike the 0.1 release of the
patchkit: it assumes a certain amount of disk and a certain level of
installation in the maintenance of a CVS or simple RCS tree being required
on systems installing the kit. One of the major mistakes I made in the
0.1 kit was the assumption that all sources to be patched would be available.
I don't see how someone with room only for the kernel sources will be able
to maintain a CVS/RCS tree. If the intent is to provide baselining as a
means of achieving patch level, I don't see how this can be done without
requiring either full sources plus the CVS'ed code tree or multiple code
trees for the kernel, src, othersrc, etc.
>>
>> The intent of the header in each file is *precisely* to "screw up"
>> selective patching.
>
>I continue to think it was, and is, *stupid*. You harp on order of
>application of patches, but this is *trivial* to do right. First of
>all, there are very few conflicting patches in practice. Second of
>all, there is no reason each patch can't have a dependency list. AIX
>does this, and the dependencies are checked automatically when a new
>patch is about to be installed. They make other mistakes, but this, at
>least, they got right. (WRT AIX, we're talking about binary patches.)
AIX's approach is the same as mine; the difference is where the interference
tables are kept. Since I was already patching the sources, I didn't see
breaking the information up as logical, given that I was using a rather
slow shell script to control everything. Yes, I dislike the "patch
drippings" in the files patched, but I didn't have a whole lot of options
at the time.
>> You assume that there will be exactly one patch.
>
>I make no such assumption.
Sorry. This was an unclear statement. What I mean was that the assumption
that patch order is irrelevant is only true if there is only one patch to a
particular file. If a single patch effects multiple files (many of them do),
then there is always a potential for conflict with another patch. One way
to get around (mostly) this restriction is to baseline patches against a
particular version -- to say, for instance, that all patches will be taken
against raw 0.1 code rather than against patched code. This is assumed by
implication with the references to CVS and RCS, but denied by the suggestion
of using a new patch to remove an old patch. It's unclear as to what was
meant, and apparently I chose the wrong meaning.
>> I think you do not appreciate the amount of effort involved in
>> providing the patchkit at it's current level.
>
>No, I *do* appreciate it, and I probably wouldn't even be using 386BSD
>were it not for the patchkit. However, it still *sucks*.
I'd probably put this as "inferior to what it could be". Saying "sucks"
could be taken to mean that we would be better off without it (0.1 without
patches being better than using the patchkit) or that 0.1 itself fell
into the same category. I'm not prepared to agree with either assessment.
Bill and Lynne put a lot of work into 0.1, and I put a lot of work into
the patchkit software; both tasks were altruistic pursuits. I don't think
anyone is expecting rewards for anything, but neither do I expect shit for
something I did for free not meeting some arbitrary standards I didn't
have available during the design process.
>>> b) Example time: If I'm a user who needs a working com driver, [...]
>
>Forget it. You obvious can't see the forest.
The "forest" is that volunteer efforts can not be held to commercial
standards; they may aspire to them, but the volunteers certainly are not
*answerable* for their efforts.
I realize that some people may rely on an overall level of operability in
386BSD; without paid commercial support, however, it is a mistake to do
so. Unlike BSDI, USL, and other commercial efforts, support is not
something that someone is guaranteed.
To take your "user wants a working driver" example to it's logical extreme,
many users have noted that it would be desirable to have a QIC 40/80
driver. Jesus Monroy may soon make a liar out of me, but one simply is
*not* available. No one has an obligation to provide one unless there
is a contractual obligation entered into by some party. Neither Jordan
nor anyone else is required to provide anything, including packaging
CGD's com drivers for distribution as a patch.
This is *not* a case of "not seeing the forest for the trees", but simply
a case of expectations.
>> I still *strongly* disagree that a totally context-free patcher can
>> be produced; I believe there will always be installation order
>> dependencies.
>
>I would never be so stupid as to deny this; however, it is incredibly
>simple to deal with.
Again, I believe we have a misunderstanding; it seemed to me (without the
benefit of a reference to CVS or RCS, implying baseling against 0.1) that
doing away with the patch context information (and who cares where it is
stored) as you suggested would remove the ability to ensure applyability
of patches. I can see now that you are still concerned about this, and
are intent on applying a different approach to solving the problem.
>> [Re: version numbering of base release]
>> This is *not* a problem to be addressed by Bill! This is a problem
>> to be addressed in the minds of the people who think all products
>> have an equal measure of progress between version numbers (ie: all
>> progress is quantized into internationally standardized units).
>
>That's a nice plateau, Terry, but it's pretty lonely up there. Most of
>us live in the real world, with real people. I, for one, can't change
>their minds on this issue.
I don't see Linux as a competitor; after all, neither the Linux or 386BSD
people are being paid for their efforts. It's a good idea to ensure that
people make an informed decision if they are to choose only one that's
best for their purposes, but I think that if people can't look further
than version numbering, their going to be hard put to make the decision
competently anyway. The version numbers haven't greatly restricted the
popularity or availability of 386BSD to date.
The only place I can see versioning as being important in any real sense
is in some third party trying to seel either 386BSD or Linux as part of
a soloution to their customer; in that case, there's nothing preventing
them from using their own versioning system for the customer's sake; even
so, this should not impact us.
I, for one, am unwilling to try to take control of major releases (and thus
versioning) away from Bill; this is his baby. Very few of us are other
than glorified camp followers, myself included.
Regards,
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------