[lkml]   [2015]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 00/13] Add kdbus implementation
On Fri, Jan 16, 2015 at 7:26 PM, Daniel Mack <> 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 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 tree doesn't actually compile against 3.19-rcX.
>>> I'm confused where we're supposed to track things now.
> The 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 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 :)


 \ /
  Last update: 2015-01-17 02:01    [W:0.064 / U:4.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site