Re: [PATCH v3 2/9] liblockdep: Wrap kernel/lockdep.c to allow usagefrom userspace

From: Peter Zijlstra
Date: Fri May 10 2013 - 06:13:12 EST


On Fri, May 10, 2013 at 11:18:16AM +0200, Peter Zijlstra wrote:
> On Thu, May 09, 2013 at 11:58:02AM -0400, Sasha Levin wrote:
> > kernel/lockdep.c deals with validating locking scenarios for
> > various architectures supported by the kernel. There isn't
> > anything kernel specific going on in lockdep, and when we
> > compare userspace to other architectures that don't have to deal
> > with irqs such as s390, they become all too similar.
> >
> > We wrap kernel/lockdep.c and include/linux/lockdep.h with
> > several headers which allow us to build and use lockdep from
> > userspace. We don't touch the kernel code itself which means
> > that any work done on lockdep in the kernel will automatically
> > benefit userspace lockdep as well!
> >
> > Signed-off-by: Sasha Levin <sasha.levin@xxxxxxxxxx>
> > ---
>
> OK, this patch is a complete fail with anything not git. Please fix it so I can
> use quilt.

So I tried patch --posix; but that makes patch unhappy too:

|--- /dev/null
|+++ b/tools/lib/lockdep/Makefile
--------------------------
No file to patch. Skipping patch.
out of 1 hunk ignored
can't find file to patch at input line 393
Perhaps you used the wrong -p or --strip option?

And while patch has a --remove-empty-files it does not recognise
--no-remove-empty-files :/

I briefly read a thread from the git mailing list where Linus and others
discussed the various weirdness around empty files and the take away was that
git would act differently by default. Because as Linus put it: "patch" is a
total piece of utterly unbelievable SH*T.

However, aside from different behaviour I don't think its that nice git-diff
creates patches that patch cannot possibly apply right...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/