On Mon, 19 Nov 2012, Noah Watkins wrote: > On Mon, Nov 19, 2012 at 5:04 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > > > > Just glanced over this, and I'm curious: > > 1) Why symlink another reference to your file_layout.h? > > I followed the same pattern as page.h in librados, but may have > misunderstood its use. When libcephfs.h is installed, it includes > > #include "file_layout.h" > > and we assume the user has -Iprefix/cephfs/. > > but in the build tree, include/cephfs isn't an includes path used, > hence the symlink. > > > 2) There's already a ceph_file_layout struct which is used "widely" > > (MDS, kernel, userspace client). It also has an accompanying function > > that does basic validity checks. > > I avoided ceph_file_layout because I was under the impression that all > of the __le64 stuff in it was very much Linux-specific. I had run into > a lot of this hacking on an OSX port. > > > FYI, there's an "unused" __le32 in the open struct (used to be for > > preferred PG). We should be able to steal that away without too much > > pain or massaging! :) > > Nice. Do you think I should revert back to using ceph_file_layout? We could avoid the whole issue by passing 4 arguments to the function... -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
