Onstream DI-30 Tape

[Kevin Buettner]

On Jun 1,  7:02pm, KeithSmith wrote:

> Kevin Buettner wrote:
> > 
> > On Jun 1,  2:59pm, KeithSmith wrote:
> > 
> > > I am prompted twice `previously applied patch
> > > detected: Assume -R?'
> > >
> > > According to the HowTo this means I am trying to
> > > "apply a patch which is below your current version
> > > number".
> > 
> > No.  It sounds to me like the patch (or a portion of it) has already
> > been applied.  Take a look at the patch and the source code that
> > you're trying to patch to see.
> > 
> 
> This is way over my head.  Is there a more common
> backup system that everyone is using that is
> easier to deal with?

I dunno.  I have an old SCSI drive that it took me a while to get
working.

> I bought the Onstream after I saw that they had a
> patch and though it would be easy to install.
> 
> Lets say I find that part of the patch has been
> installed already - then what?

You must make sure it's been installed in its entirety and then
you're good to go.

> Could I already have a tape device compiled into
> my kernel already? - how would I check this?

Yes; it could be that the distribution vendor has already applied the
patch for you.

You're not going to like this, but...

You need to read the patch and look at the source code to which it
pertains to see if the patch has already been applied.  This does not
mean that you have to understand what the patch does or what the
source code in question does.

Patches are really not that hard to understand.  I'll tell you a
little bit about them and give you an example to help you out.

First, patches are generated with the ``diff'' program.  If you
were creating a patch, you might do it like this:

    diff -u old-source new-source > mypatch

Usually you want to diff entire directories in which case you'd
do

    diff -ur orig-sources new-sources > mypatch

(substitute the names as appropriate.)

The -u switch says to create unidiffs (which is what I prefer).  You
will also see patches created with the -C switch.  These work just
fine with the patch program, but IMO, are a bit harder for a human
to read.

Now for an example:

diff -ur ../../orig/gdb-sourceware/varobj.c ./varobj.c
--- ../../orig/gdb-sourceware/varobj.c	Sat May 27 17:10:26 2000
+++ ./varobj.c	Thu Jun  1 23:33:16 2000
@@ -1030,10 +1030,8 @@
  */
 
 static int
-delete_variable (resultp, var, only_children_p)
-     struct cpstack **resultp;
-     struct varobj *var;
-     int only_children_p;
+delete_variable (struct cpstack **resultp, struct varobj *var,
+		 int only_children_p)
 {
   int delcount = 0;
 

The above is from a patch that I'm working on for gdb.  (I want to
replace all of the traditional C function definitions with ISO C
prototyped definitions and am working on a script to do this for me.)

The first three lines have a bit of redundancy built into them.  The
first shows you the diff command that was used to produce this diff.
The second shows the name of the original source file, and the third
shows you the name of the source file to patch.  (Many times you need
to examine the third line to figure out what the -p switch should be.)

The line beginning with @@ is the start of a patch hunk.  The hunk starts
at the @@ line (or perhaps one line after) and continues until either the
end of the file or the next @@ line whichever comes first.

Following the @@ line, you'll see three lines of context.  This helps
the patch program figure out where to make changes in the event that
the file being patched doesn't exactly match the original file.  Note
too that there is a line number on the @@ line which helps tell patch
where to start looking in the file to patch.

In the above patch, there are four lines that begin with a minus sign.
These lines were removed from the file.

The lines beginning with a plus sign are lines that were added.

Finally, there are three more lines of context.

Now, let us suppose that you wanted to see whether or not the above
patch had already been applied.  What you'd do is look in your sources
(in this case, the gdb sources) and find the file named varobj.c.  Next
you'd go to line 1030 and look for the delete_variable() function.
If the function declaration resembles the one with the minus signs
preceding it in the patch, you know that the patch has NOT been applied.
OTOH, if it matches the lines with the plus signs, it most definitely
has been applied.

....

Given the message that you got from the patch program, I think it's
likely that the patch in question has already been applied.  However,
the only way to make sure is to look it over.  After all, it's possible
that the kernel developers (or your distribution vendor) have applied
patches of their own which are a subset of the patches that you got
from OnStream.