[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+5PVA4sLgTFBgdfgBKzXeWbXOkPVCDwOOVDrefUSCU_srm8Kw@mail.gmail.com>
Date: Fri, 16 Jan 2015 19:41:20 -0500
From: Josh Boyer <jwboyer@...oraproject.org>
To: Daniel Mack <daniel@...que.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
Andy Lutomirski <luto@...capital.net>,
linux-api@...r.kernel.org,
"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
David Herrmann <dh.herrmann@...il.com>, tixxdz@...ndz.org
Subject: Re: [PATCH v3 00/13] Add kdbus implementation
On Fri, Jan 16, 2015 at 7:26 PM, Daniel Mack <daniel@...que.org> wrote:
> Hi Josh,
>
> On 01/16/2015 11:18 PM, Greg Kroah-Hartman wrote:
>> On Fri, Jan 16, 2015 at 05:07:25PM -0500, Josh Boyer wrote:
>>> The code.google.com tree has commits
>>> from 2 days ago, but it still calls d_materialise_unique in fs.c
>>> whereas the patchset you've posted uses the correct d_splice_alias.
>>> So the code.google.com tree doesn't actually compile against 3.19-rcX.
>>>
>>> I'm confused where we're supposed to track things now.
>
> The code.google.com repository is where we do all the development, and
> the code is made to build external kernel modules for 3.18. The patches
> sent in this series are meant for 3.19 and 3.20 kernels, and while they
> are based on the exact same sources, the patches differ in the following
> minor details:
>
> * Code is moved to appropriate locations, such as ipc/kdbus,
> include/uapi, tools/testing/selftests/kdbus/, Documentation/ etc.
>
> * Include file location amendments, "kdbus.h" vs. <uapi/linux/kdbus.h>
>
> * Added iov_iter_kvec() usage, as that's a new API in v3.19
>
> * The file system magic number is moved to include/uapi/linux/magic.h
>
> * d_materialise_unique() is renamed to d_splice_alias() to catch up
> with changes in 3.19
>
>
> The commit this patch set is based on is tagged as "lkml-v3" in the
> upstream repository now.
OK, thanks for the explanation.
I wonder if it would be possible to have branches for each kernel
version in the code.google.com repo? I build kdbus against a number
of kernels and trying to chase down different repos and patch sets to
match might get to be a chore. I mean, I'm all for doing closet
development to get stuff ready for upstream but it's hard for others
to keep up when the closet keeps moving :)
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists