Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!zaphod.mps.ohio-state.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: <1993Mar21.014401.2911@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <g89r4222.732307558@kudu> <C409MC.n1D@agora.rain.com> <1obts0$doq@hal.gnu.ai.mit.edu>
Date: Sun, 21 Mar 93 01:44:01 GMT
Lines: 243
In article <1obts0$doq@hal.gnu.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>
>What I would like to create is a streamlined patching tool that would
>make patching, replacing, and removing files easier, would not do
>blatantly stupid things like the large patchkit header in each file,
>which totally screws up selective patching, and a moderated newsgroup
>`comp.os.386bsd.patches' that would contain one article per patch, and
>would have a much lower latency (on the order of one or two weeks
>average).
The currently patch facility (and my choice of "blatantly stupid things
like the large patchkit header in each file") are the result of several
decisions based on the "patch" and "diff" software's operation and the
fact that we don't control the arguments, operation, maintenance, or
output format of either of these utilities.
The intent of the header in each file is *precisely* to "screw up" selective
patching.
For instance, how would you produce patches for the following three
changes to a (pseudocode) file:
ORIGINAL:
if( totalmem > 16M || kernelsize > 640K || external_cache == TRUE)
print( "SCSI DRIVERS WILL FAIL ON THIS MACHINE!\n")
AFTER PATCH 1:
/* XXX added bounce buffers for SCSI DMA on ISA machines with >16<*/
if( /*totalmem > 16M ||*/ kernelsize > 640K || external_cache == TRUE)
print( "SCSI DRIVERS WILL FAIL ON THIS MACHINE!\n")
AFTER PATCH 2:
/* XXX added "noncachable" bit to page table for SCSI DMA buffers*/
/* XXX added bounce buffers for SCSI DMA on ISA machines with >16<*/
if( /*totalmem > 16M ||*/ kernelsize > 640K /*|| external_cache == TRUE*/)
print( "SCSI DRIVERS WILL FAIL ON THIS MACHINE!\n")
AFTER PATCH 3:
/* XXX fixed SCSI loading of kernels to allow loading to high memory*/
/* XXX added "noncachable" bit to page table for SCSI DMA buffers*/
/* XXX added bounce buffers for SCSI DMA on ISA machines with >16<*/
#ifdef OMIT
if( /*totalmem > 16M ||*/ kernelsize > 640K /*|| external_cache == TRUE*/)
print( "SCSI DRIVERS WILL FAIL ON THIS MACHINE!\n")
#endif /* OMIT*/
I don't see any way that these patches can correctly be applied out of
order and function given the current "patch" and "diff" commands. By
having a "cannonical" ordering to patches, you avoid the problem.
For patches which effect single files not effected by other patches, yes,
you can "just apply them... for now; what about subsequent patches to the
same file? You assume that there will be exactly one patch.
All of the patches in the patchkit come as a control file and a series of
patches. There is *nothing* preventing you from individually applying
them out of order (other than the fact that a patch that relies on a
previous patch will fail with a .rej file which *won't* cause the patch
program to return an error -- it's undetectable without an "ls").
I think you do not appreciate the amount of effort involved in providing
the patchkit at it's current level. I, Nate, Rodney, Jordan, Chris, and
others have had to collect the patches from various sources, and then,
because the diffs weren't taken from a unified source base, we have to
*arbirarily* pick an installation order, and hand-install all patches
(some of them damn large) against each of the source files effected.
The patch headers you despise are a distributed interference graph of the
patches, and enforce sequence to ensure installabilty of all the patches
in the patch kit (the ability to compute transitive closure over all of
the patched files). The reason for centralized control is to ensure that a
hand-applied patch is not applied to a file containing a patch without an
entry in the interference graph.
>Obviously, this is a fair amount of work, and I can't do it all by
>myself. Anyone wishing to help out (or even just say `Go for it!') is
>welcome to send me mail.
You *can* go ahead an ditribute patches the way you want, but I assure you
that the vast majority of them will be unusable to the vast majority of
users without each of them *individually* duplicating the effort of hand
applying the patches to files where conflicts occur. I also *guarantee* you
that posting order as a patch order enforcement mechanism is an inadequate
warrantor of usability unless every installs all patches since post 1; even
then, there is no guarantee that post-time in any way reflects diff time,
or that posts from sperate sites are not interleaved and effect the same
files. The only way you might get around this is to present yourself as a
moderator for the "patch group" and do exactly what Jordan is doing now.
This yields a single point of failure for what turn out to be bad patches
unless you also ensure testing, as has been done with previous patchkits.
I, for one, would not to install a patch that Rodney or Chris or others
haven't beaten on. 8-).
----
I can't fault you for the majority of your reply. I'm on the patchkit list
(probably as more of a courtesy than anything else, as I've been barely
able to keep my hand in lately) and I *have* seen stuff about 0.2.2; you
would have to check with the mailing list maintainer to ensure your address
is correct in the list to make sure that the mailing to you haven't simply
been lost.
>b) Example time: If I'm a user who needs a working com driver, what do
>I do? If I know there's going to be one in the next patchkit, I might
>wait. But at the moment, I haven't the foggiest notion, so I'll
>probably go get cgd's, and have to back it out later. This is tedious,
>especially, when I have to do it for N patches and new drivers.
I have to take issue with this, simply because it's mainly a configuration
problem, not a patch problem, and because this is *alsway* going to be
true. If someone want's something that's not in a code-cut release, like
0.1, 0.1p0.1, 0.1p0.2, 0.1p0.2.1, etc., then yes, the will have to deal
with "raw" (unpackaged) patches. The same is true if you want shared libs
or loadable kernel modules or some types of ethernet and SCSI drivers. The
fact is, 386BSD isn't a supported product. Those of us who *do* do support
(such as Nate, Myself, Amancio, and many others) generally support or fix
what we feel like supporting or fixing at the time.
>c) If the patchkit mechanism weren't *braindead*, I wouldn't have to
>back anything out.
Again, I can only cite the tools available for building it. If you think
you can do better than me, you're welcome to go ahead. I certainly would
not want to tackle doing everyting that needs to be done *plus* maintaining
new and improved (and incompatable) versions of Larry Wall's patch program
or of the diff utility. I *won't* be Larry Wall's appologist; I think that
the "patch" program he produced is much, much better than what was there
before (ed scripts), and I probably wouldn't have written the "patches"
program without it.
I still *strongly* disagree that a totally context-free patcher can be
produced; I believe there will always be installation order dependencies.
>And finally, not really related to the quoted article:
>
>d) The patchkit process is really starting to *tick* me off. If you
>want to release interim or preliminary patches, that's *fine*, but
>*every bloody quasi-official patch, in every bloody `alpha', `beta', or
>`official' release* should have a unique identifier, and the patchkit
>mechanism should have some way of automatically backing out (possibly
>through a later reverse-patch) bad or replaced patches.
Unique identifiers are a good idea; I think the main problem here has been
that in the initial patchkit, I didn't take into account people who had a
partial installation that they wished to apply patches too. I still think
that partial installations should be discouraged, but this *was* an omission
on my part.
Part of the goal of the 0.2 kit, at least as far as I understood it from
Nate, was to ensure the numbers didn't need to change in the future.
>e) Patches should be rolled in much more quickly. There is no reason
>(other than losingness in the current implementation) that a single
>patch cannot be blessed and incorporated with much lower latency.
This is true if the diffs came off a fully patched system. Since patch
order *does* have to be maintained (in my opinion and with current tools
and totally neglecting the part the "patches" program plays in enforcing
order), most diffs result in a hand-application of the patch being required.
This would not be true if the people writing the code were the people who
were maintainging the patch kit who were the people doing the testing of
the patches on all sorts of hardware; but this is not the case. Many
people throw out code like congress uses money -- fast an furious; the
last thing we need to do is obligate these people to doing something they
don't enjoy before we "let" them code. I think everyone remembers when
a few people were bitching about Chris' serial drivers tried to ruin it
for everyone.
Blessing *really* requires centralized assignment of patch order to ensure
each patch can be applied without problems. If you can get around the
context dependencies (this would necessitate rewriting diff and patch),
*PLEASE* do! I was unable to do this, and the resulting requirement of
centralized coordination very nearly kept me from releasing the first
patch kit as well. I don't like it any more than you, although it *has*
resulted in a two-tier process, where the vast majority of people are in
the second tier (unless the apply posted patches themselves) are pretty
much guaranteed that the patches they get through the patchkit channel
*have been tested by >someone< to make sure they >work<*.
>f) NEVER replace a file on a FTP site with one of the same name if it
>has *any* changes, no matter how small! This confuses the bloody
>*Hell* out of people who may have already downloaded it, and this
>confusion propagates.
Gotta agree with this, although I have to say that in the case of the
84 and up pathes, this was more due to a misunderstanding of what should
be made publically available than anything else.
>I wouldn't be half as annoyed if people at least seemed to realize that
>they were doing the wrong thing. I can't believe anyone actually
>thinks the current mechanism is good.
Nope; just better than the alternative, which was 90% of all patches being
usable only with a great deal of work.
>Take an example from the Linux crowd: Quite a number of people have
>told me that they chose Linux because they `see development happening
>faster'. What they're really saying is that they see new versions of
>programs released frequently; this gives the appearance that a lot is
>happening, even if the changes are only small, and they don't even
>bother to update their copy most of the time.
>
>Of course, the version number is a related issue. The Linux release
>number `0.99' is close enough to `1.0' that people think it's right on
>the brink of being stable (even though I've seen some major changes
>recently, like new file systems). 386BSD, by contrast, is numbered
>`0.1', which gives people the impression that it has a long way to go.
>While I think it's silly, and I personally find 386BSD much more
>stable and complete, most people really are used by^H^Hto corporate
>version numbering, and no number of words will sway their perception.
I think (as you suggest) that this is traceable to the rate at which new
code is released by Bill; the version number isn't changing as quickly,
and so there is an assumption that developement isn't going on. 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).
I hope I've answered some questions as to why the patchkit software is the
way it is right now. If you want to change or improve it, please feel
free to do so, but please also keep in mind the constraints which have
forced it into it's present shape.
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
-------------------------------------------------------------------------------