From: Alasdair G Kergon <agk@uk.sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Writing forward compatible applications using /proc
Date: Mon, 13 Aug 2001 16:13:01 +0100 [thread overview]
Message-ID: <20010813161301.B6466@uk.sistina.com> (raw)
In-Reply-To: <20010812221650.A6589@vestdata.no>; from lvm@ragnark.vestdata.no on Sun, Aug 12, 2001 at 10:16:50PM +0200
On Sun, Aug 12, 2001 at 10:16:50PM +0200, Ragnar Kj?rstad wrote:
> On Sun, Aug 12, 2001 at 08:07:02PM +0100, Joe Thornber wrote:
> > I would much rather see people wrapping the tools than using liblvm, in fact
> > liblvm will probably disappear in the future.
> Why will liblvm disappear? To me using a library interface seems much
> nicer than wrapping applications.
Let's put this another way.
In the 'experimental' branch each tool has been converted into a
function and they have all been linked into a single 'lvm'
binary. This binary takes lvm commands from standard input
and processes them. Or it can be invoked with argv[0] set to
the name of an existing tool (eg 'ln lvm pvcreate') and then it
will behave as that tool. There are no plans to change existing
command line arguments etc. However, in the interests of
achieving consistency between the tools and making it easy to
handle their output reliably, there are likely to be minor
changes to the output formats, error codes, signal-handling etc.
The *existing* liblvm is very dependent on internal LVM structure.
Significant internal structural changes are on the cards, so the
existing liblvm is likely to disappear.
My thinking is that, for future maintainability, the interface into
lvm should be at the level of the command-line tools, rather than
the level of the existing liblvm. Where there are functions in
liblvm that people need to call independently (any examples?), then
we should either adapt existing tools or create new ones to provide
this.
I envisage any 'wrapper' application (eg. GUI) as simply opening a
pipe/socket to 'lvm --condensed-output' (say) and passing individual
lvm commands in and getting responses back in a consistent,
condensed text format. Alternatively it could call the tools
through a new library - but the functionality this would expose
would be the same as that provided by the command line tools.
Alasdair
--
agk@uk.sistina.com
next prev parent reply other threads:[~2001-08-13 15:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-12 3:57 [linux-lvm] Writing forward compatible applications using /proc Jason Tackaberry
2001-08-12 13:54 ` José Luis Domingo López
2001-08-12 15:38 ` Jason Tackaberry
2001-08-12 18:39 ` José Luis Domingo López
2001-08-12 16:39 ` Steven Lembark
2001-08-13 1:55 ` Paul Jakma
2001-08-12 17:10 ` Eric M. Hopper
2001-08-12 22:21 ` José Luis Domingo López
2001-08-12 20:46 ` Ragnar Kjørstad
2001-08-12 22:35 ` Wichert Akkerman
2001-08-12 20:21 ` toon
2001-08-12 19:07 ` Joe Thornber
2001-08-12 19:13 ` Steven Lembark
2001-08-12 19:26 ` Joe Thornber
2001-08-12 19:51 ` Jason Tackaberry
2001-08-12 20:16 ` Ragnar Kjørstad
2001-08-13 9:08 ` Joe Thornber
2001-08-13 11:27 ` Wichert Akkerman
2001-08-13 12:48 ` Terje Kvernes
2001-08-13 23:49 ` Ragnar Kjørstad
2001-08-14 13:36 ` Heinz J . Mauelshagen
2001-08-14 0:31 ` Nathan Scott
2001-08-14 13:33 ` Heinz J . Mauelshagen
2001-08-13 15:13 ` Alasdair G Kergon [this message]
2001-08-13 17:58 ` Jason Tackaberry
2001-08-13 19:44 ` Michael Tokarev
2001-08-13 19:49 ` Wichert Akkerman
2001-08-13 20:18 ` Goetz Bock
2001-08-13 20:47 ` Joe Thornber
2001-08-13 20:31 ` Joe Thornber
2001-08-14 3:04 ` Mark van Walraven
2001-08-14 8:14 ` Joe Thornber
2001-08-14 17:50 ` Ragnar Kjørstad
2001-08-15 8:58 ` Heinz J . Mauelshagen
2001-08-13 9:10 ` Terje Kvernes
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=20010813161301.B6466@uk.sistina.com \
--to=agk@uk.sistina.com \
--cc=linux-lvm@sistina.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox