On Wed, Apr 20, 2011 at 10:03 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Wed, 20 Apr 2011, Colin McCabe wrote: >> Hi guys, >> >> I pushed a branch with a revised libceph API. The main changes: >> >> * similar appearance to librados. It should be intuitive if you've >> used librados. >> * The new API allows multiple ceph clusters to be open at once >> (although the implementation doesn't support this yet) >> * ability to pass a "root" argument to ceph_mount >> * add support for reading configuration files and choosing whether to parse argv >> * simpler ceph_getcwd >> * unmount can't fail (the library always cleans up after itself) >> >> The branch is at >> http://ceph.newdream.net/git/?p=ceph.git;a=shortlog;h=refs/heads/libceph_api >> >> Let me know what you think! > > Can we combine the ceph_connect() and ceph_mount() into one thing? Does > that make sense? If so, maybe it should be ceph_mount_t and not > ceph_cluster_t or something. Good idea. > > The (re/ab)use of DIR* was possibly not the wisest choice in the original > API (and Client.h for that matter?). Now might be the time to use a more > reasonably named typedef. Looking at client/Client.cc, it seems to be using DIR* as a kind of opaque pointer. Not a good call, because DIR is not opaque to anyone who has included dirent.h. I'll try replacing it with libceph_dir_t* or something like that. > > A few of the methods can probably go away (things like ceph_mkdirs) or be > cleaned up (the layout get/set stuff). Looks like Hadoop and Hypertable are using mkdirs. Hadoop doesn't seem to have a "regular" mkdir... looks like everything is created via the equivalent of mkdir -p. Maybe that is a good enough reason to keep it? I don't know. The get/set functions for layout do seem to need a cleanup. There's no getter for default_file_strip_count, for one thing. Also the names don't seem to quite match between the getters and setters, which doesn't help. sincerely, Colin -- 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
