On Fri, Jan 16, 2015 at 7:26 PM, Daniel Mack <daniel@xxxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
