From: Terje Kvernes <terjekv@math.uio.no>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Writing forward compatible applications using /proc
Date: 13 Aug 2001 11:10:43 +0200 [thread overview]
Message-ID: <wxxhevctje4.fsf@nommo.uio.no> (raw)
In-Reply-To: Jason Tackaberry's message of "Sat, 11 Aug 2001 23:57:18 -0400"
Jason Tackaberry <tack@linux.com> writes:
> I have some ideas for a comprehensive GUI disk administration tool,
> and I am first thinking about some of the issues I'll face regarding
> interfacing with controllers, disks, partitions, md, and LVM.
cool. I've written a perl module to interface LVM via /proc. if
you're interested I'll repost some of the code here. it's a backend,
totally seperate from any representation of the data.
> I am curious if it's a silly idea to write an application that
> relies on the data in /proc?
not really. some of the tools need special permissions to be run,
and I _might_ want to have a quick peek at my LVM status without
being root. besides, it's a lot cleaner (IMHO) than doing piping
things to a process and catching the output, like the suggestion is
atm.
> I don't mind having to release a new update to be compatible with a
> new format in /proc every once and a while, but if it's constantly a
> moving target I may want to look at alternatives.
you'll have to keep somethings in mind, before 0.9.1 beta 8 the PV's
listed in /proc only had their basename listed. using devfs this
could break badly, as you'd get easily get two identical
identifiers. so you'd still have to check what data you're getting
and see what you can, or more importantly can't, do.
> I also have the same question with LVM related tools. Is it sane to
> try to wrap a GUI around lvm tools or is there some API approach
> that would be better?
I've wrapped the tools to do the dirtywork. as in, I use create a
lvextend-command when someone does a "$lv->size('+1G')".
--
Terje
prev parent reply other threads:[~2001-08-13 9:10 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
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 [this message]
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=wxxhevctje4.fsf@nommo.uio.no \
--to=terjekv@math.uio.no \
--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