All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dale Kemp <dale@inet.net.nz>
To: Mauelshagen@Sistina.com
Cc: Linux LVM mailing list <linux-lvm@msede.com>
Subject: Re: [linux-lvm] LVM /dev and /proc problems and change proposal
Date: Sun, 25 Jun 2000 23:35:41 +1200	[thread overview]
Message-ID: <3955EE8D.15AE858A@inet.net.nz> (raw)
In-Reply-To: 20000625131619.A3679@hmsysv.t-online.de

> > And we don't know
> > what users are going to call their volume groups and we don't know what
> > device names will be created in the future.
>
> vgrename(8) is able to address that.

That's not the point I'm making here.

    # vgcreate yup0
    # etc...

Creates /dev/yup0 and all is well...

Then an upgrade occurs with support for the new yup devices from Yups(tm)
technology. Devices /dev/yup[0-5] are created, or it fails(?). If your yup0 was
in /dev/lvm/yup0 then things would carry on like normal. We don't know
what the user will name the vg's and we don't know the names of new devices
to be added to linux. By using a sub directory:

    - You keep all the stuff together in one place (well almost /etc/lvm/ /dev/lvm/
...)
    - You get around any future name clash problems
    - Its easier to find what your looking for
    - Its just plain tidier
    - Its a simple to do

> > > There's a preprocessor definition LVM_DIR_PREFIX in the code, which
> > > supports this already.
> >
> > So I see. The simplest solution is to change this default prefix, and have the
> > lvm stuff self-contained in its own subdirectory.
>
> Yes.
> Please give it a try and tell me if it works.

Ok - I will. I suspect it will work fine looking at the code.

> > > Yep.
> > > Already on the TODO list.
> > > I share your point of view in regard to /proc.
> >
> > The need for /proc/lvm/... is simular to that for /dev/lvm/...
>
> More or less.
>
> /proc/* is for programs to parse the contained information.
>
> Therfore its not primarily addressing a real name clash problem
> but the answer to the request for easy parsing.

Yes for user and machine.

-- Dale.

  reply	other threads:[~2000-06-25 11:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-25  6:35 [linux-lvm] LVM /dev and /proc problems and change proposal Dale Kemp
2000-06-25  8:30 ` Heinz J. Mauelshagen
2000-06-25 10:01   ` Dale Kemp
2000-06-25 11:16     ` Heinz J. Mauelshagen
2000-06-25 11:35       ` Dale Kemp [this message]
     [not found]       ` <3956DF94.218CA65E@inet.net.nz>
2000-06-26  7:13         ` Heinz J. Mauelshagen

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=3955EE8D.15AE858A@inet.net.nz \
    --to=dale@inet.net.nz \
    --cc=Mauelshagen@Sistina.com \
    --cc=linux-lvm@msede.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.