NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5683

Text File | 1992-09-14 | 8.1 KB | 155 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Re: 386BSD PARTIAL PATCH KIT NOW AVAILABLE
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
References: <[e-mail]> <[e-mail]>
Date: Mon, 14 Sep 92 17:24:27 GMT
Lines: 143

In article <[e-mail]> [e-mail] (David Le Blanc) writes:
>[e-mail] (A Wizard of Earth C) writes:
>
>>I have uploaded the first 19 patches and the patchkit software to the
>>directory /pub/incoming/terry on agate.berkeley.edu.  This is not a
>>complete set, as there are still 10-20 patches not yet in patchkit format.
>
>>The following is a list of the patches in the current patch kit.
>>Remember that the patchkit expects to start with a "virgin" kernel... no
>>strange hacks allowed.
>
>Please note that this is rather rude, and very restrictive.

I assume that you mean the reference to a '"virgin" kernel.  If you can tell
me how to write a patch program that doesn't require context differences,
I'll be happy to incorporate (and patent 8-)) the technology.

Until then, the patches are incremental in nature.  This means for all the
existing patches, I have to start with a "baseline"... ie: a "virgin" kernel,
or some agreed upon baseline.  It also means that, in order to produce the
patches in the first place, I have to *manually* go through them to insure
that conflicts between patches are resolved (since there was no incremental
management of the patches in the first place).

If you produce a patch to wd.c and I produce a patch to wd.c, and joe blow
produces a patch to wd.c, there has to be an *order* to the patches so that
there aren't any conflicts.  There has to be *enforcement* of this order,
since I can't tell what patches you already have installed, and for the
context to be correct, the order *must* be enforced.  There's no other
way I can see to get the majority of patches out to the majority of
people.  I have been keeping multiple source trees for baselining from day
1 to facilitate this.

>Is your patch kit going to help me with the bus mouse driver I have to patch
>in? Or make things hard?

If you are talking about the Logitech one posted here, then it will simply
install as a patch, as will the AT&T EN100/PC-10 NAU ethernet board drivers.

It's true that I haven't taken into account automatic rebuild (at least not
yet) of the patched files.  This is partly because I am rolling in the 4.3
Reno patches posted to the net, and I can't be guaranteed a full source tree
anywhere but the kernel (how do I remake "init" after it is patched, for
example?).  I will probably be including a machanism for kernel rebuild
and a tag to indicate that it is necessary, but have done nothing on it so
far.  I suppose I will have to include the running of MAKEDEV as well.

I have also not placed it in an easily accessable area; casual browsers
won't find it, and it won't be echoed to other sites mirroring agate.
This is intentional; the thing is admittedly "alpha".  In particular, the
code identifying falure to install the patch and patches 14 and 16 have
problems.  Patches 14 and 16 can be incrementally deinstalled until this
is fixed (it's fixed now, but upload will wait until tonight).  When it
goes "beta", meaning that I know all patches so far are represented and
that they install correctly, I will ask Chris to make the thing public,
and it will get mirrored everywhere.

>Will it work with, or cause problems for those installing the patches for
>using X386 ?

Obviously, if the context diffs for the X are not taken against baseline code,
there will be problems.  Certainly there will *not* be problems if the diffs
are against a "fully patched" kernel, or if the affected files are patch
level 0 (new files) or part of the original distribution, and are not touched
by the patch kit.

>Will the X386 patches be incorporated?

The ones on agate in the incoming/X386 directory *have been*; they just
haven't been posted yet (I felt it would be easier to debug 20 patches
at the same time rather than 40 of them -- so sue me).  If there are more
recent versions, they will require incorporation against baseline, which
is defines as the patches you have applied and the patch level of the
file affected.

>Granted I have not seen the patchkit software, I would be happy if you
>allowed a modular approach, so that I could add a patch to the
>'patchkit' directory, edit some central config file, and run the software.
>
>I may then select the new patch, and have it applied.

It is modular; however, because I haven't been able to work out how to
(automatically, preferrably) manage baselining, I haven't distributed the
patch-building software (mkpatch) or it's documentation, or the tutorial.
I am currently trying to work with Nate (the bug list keeper) on a way to
manage this, and when we have something, I am sure we will post.  Until
then, I will probably keep incorporating patches as they are posted.  To
directly answer, the question, however, NO, YOU CAN NOT CURRENTLY MAKE
NEW PATCHES BECAUSE YOU DO NOT HAVE THE PATCH PRODUCTION SOFTWARE, AND
ANYONE THINKING OF MAKING PATCHES IS STRONGLY DISCOURAGED FROM PUTTING
THEM IN PATCHKIT FORMAT THEMSELVES BECAUSE OF THE CONFLICT MANAGEMENT
ISSUES WHICH STILL NEED TO BE ADDRESSED.

>Could all patches be kept in a compressed form?

Initially, all the patches *are* in compressed form.  The failure of a
compression of compressed data is why the file containing both the patch
kits and the patch software is simply a tar archive (as previously posted).

I do *not* store installed patches or ready-to-install patches in compressed
form; however, the patch generation software does pack them that way for
distribution.

I could not worry too much about disk space, since the way things are
currently arranged, previous patch levels *must* be left around for subsequent
patches to know what has been installed.  Later, this will be replaced with
patch removal via "patch -R".  I haven't done that yet.


Bottom line:  I make some assumptions which cost a small amount of disk space,
which may be too expensive for people who only have a "very small" amount of
disk.  These people are unlikely to benefit from the installation of patches
anyway, since they are unlikely to be able to rebuild their kernel.  I make
some assumptions about baselining that means you have to have a "virgin"
kernel with no patches to the files to be patched.  This is the assumption
that practically all patch posters have held to so far.  I make it so an
idiot can patch kernels (not that I expect many idiots to be able to con
anyone into installing the patch software for them, much less knowing how
to usae ftp).  I make it so that you can apply multiple patches to the same
file.  I make non-prerequisite patches optional (admittedly a value judgement
on my part).  I provide a common mechanism for patch distribution so that
patches and new files are not in a bad format because someon forgot the "-c"
option to diff or put the file name parameters in the wrong order.

I am *not* setting myself up as "patch god".  Since I expect that 0.2 will
eventually be released, that would be a stupid move on my part, not to mention
that I really already have my hands full at the moment with other things.  I
realize that this will probably be the short term effect of "official" patch
numbers, and incremental installation, and am working dilligently to resolve
this.  Until then, if you don't like it, don't use it.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
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
-------------------------------------------------------------------------------