From: Goffredo Baroncelli <kreijack@inwind.it>
To: Roman Mamedov <rm@romanrm.net>, Stef Bon <stefbon@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Plans for a library for btrfs?
Date: Fri, 29 May 2015 19:02:59 +0200 [thread overview]
Message-ID: <55689BC3.40306@inwind.it> (raw)
In-Reply-To: <20150529193123.1ecb5d8a@natsu>
On 2015-05-29 16:31, Roman Mamedov wrote:
> On Wed, 27 May 2015 14:31:28 +0200
> Stef Bon <stefbon@gmail.com> wrote:
>
>> This program, which I've called fuse-backup, creates backup subvolumes
>> and snapshots by calling an extrenal script, which does something
>> like:
>>
>> btrfs subvolume snapshot -r %PathToBackup%/ %PathToSnapshot%
>>
>> This works perfect, but are there any plans to do this with a library?
>
> If this works perfect, then what is the rationale for needing a library?
The problem in calling another executable, is that is very difficult to parse the program output.
For "btrfs sub snap" it is easy; but what about "btrfs fi df" or "btrfs fi show" ?
> Do you see a clear reason aside from any vague "it's supposed to be that way".
> In the Unix land it is perfectly normal for programs to call other
> self-contained programs to do their self-contained jobs:
Right, but now btrfs is a collection of tools; I don't think that it could e considered a "self-contained programs"... Other programs (eg systemd, udev) rewrite some code in order to avoid to call an external executable. This leads to code duplication with all the associated problems...
> http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877684
> Not everything must to be a library linked into your main executable, some
> separation and calling external programs to do stuff such as mkfs or snapshot
> management seems perfectly fine and even better from the debug-ability
> standpoint.
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2015-05-29 17:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 12:31 Plans for a library for btrfs? Stef Bon
2015-05-27 17:39 ` Duncan
2015-05-29 14:04 ` David Sterba
2015-05-29 14:31 ` Roman Mamedov
2015-05-29 17:02 ` Goffredo Baroncelli [this message]
2015-05-29 19:13 ` Juan Orti Alcaine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55689BC3.40306@inwind.it \
--to=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
--cc=stefbon@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.