On Tue, Apr 09, 2013 at 08:37:12AM +0200, Jan Schmidt wrote: > On 06.04.2013 20:30, Eric Sandeen wrote: > > From: Mark Fasheh <mfasheh@xxxxxxx> > > > > btrfs-progs: re-add send-test > > > > send-test.c links against libbtrfs and uses the send functionality provided > > to decode and print a send stream to the console. > > This looks pretty much like fardump from Arne's far repository: AFAICS, send-test uses the NO_FILE_DATA mode, and the implementation differes (it calls into btrfs_read_and_process_send_stream, unlike fardump that dumps the attributes as it finds them), but the goal of the utility seems to be the same. > In my opinion, one of the next steps would be getting the logic used in > btrfs receive into a generic far lib, which itself would link against > libbtrfs to take the btrfs part from there. So, "btrfs receive" on the > command line would become a stub calling something in the yet to create > far lib, which itself would call hooks back to libbtrfs. Sounds good in the long term. > I have no plan ready how to build btrfs progs if we're doing such a > shift, that would have to be sorted out. > > My goal is to get everything that could be shared with other filesystems > out of btrfs-progs into a far lib, and the send-test sent here > definitely falls into that category; plus: it already exists outside > btrfs-progs, unless I'm missing something. I don't know if Mark has other plans with send-test or if it's a debugging or development utility. Merging functinality with FAR will take some time. Are you fine with keeping send-test in btrfsprogs until then? It's not built by default so nobody will probably rely on it so it could get replaced by fardump eventually. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
