All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Niehusmann <jan@gondor.com>
To: Andreas Dilger <adilger@turbolinux.com>
Cc: linux-lvm@msede.com
Subject: [linux-lvm] lvm.h kernel/userspace differences
Date: Fri, 1 Sep 2000 13:29:36 +0200	[thread overview]
Message-ID: <20000901132936.A3526@gondor.com> (raw)
In-Reply-To: <200009010540.XAA04818@lynx.turbolabs.com>; from adilger@turbolinux.com on Thu, Aug 31, 2000 at 11:40:10PM -0600

On Thu, Aug 31, 2000 at 11:40:10PM -0600, Andreas Dilger wrote:
> Jan Niehusmann, you write:
> > I think it's better not to use linux/lvm.h because kernel headers may belong
> > to an older kernel version without lvm support. (Linus said on linux-kernel
> > that he prefers that /usr/include/linux and /usr/src/linux are of the kernel
> > version used when glibc was compiled)
> There was always something that confused me, and I never got a response
> back from Heinz - in the 0.8final user tools/lib/lvm.h it says the IOP
> version is 7, but the 2.4 kernel lvm.h has IOP version 6 right now,
> so it shouldn't work, but I think the wrong header is being used...

I just compared lvm.h from 0.8final and from linux 2.4.0-test7 (which is 
running on this computer). You are right, IOP version is different.

But: Kernel defines LVM_DRIVER_IOP_VERSION to "6" and exports it via 
ioctl LVM_GET_IOP_VERSION. Userspace requests this in lvm_get_iop_version.
The only place where lvm_get_iop_version gets called is LVM_CHECK_IOP in
lvm_user.h, where the result (the kernel IOP version) is compared to
LVM_LIB_IOP_VERSION (and not to LVM_DRIVER_IOP_VERSION), and 
LVM_LIB_IOP_VERSION is "6", as defined in liblvm.h. 


Additionaly, the following things have changed between 0.8final lvm.h and
the linux-2.4.0-test7 version:

- some includes and #ifdef KERNEL have changed, nothing that should cause
  binary incompatibilities, probably

- many type changes uint -> uint32_t and stuff like that. It looks like only
  the names have changed, not the real types, so no problem, again. 

- kernel's lv_v2_t has an additional field "uint8_t __unused;" _in the middle_
  of the struct. Huh. What's that?
  
- in the kernel, there is an lv_disk_v2_t that's missing from 0.8final. 
  But it's identical to lv_disk_v1_t, so what's the point?

- pv_flush_req_t is missing the field "kdev_t pv_dev" in kernel. As it is 
  shorter in kernel, and the missing field is at the end, and the struct is
  only copied into the kernel, this shouldn't cause problems. But things like
  that may become a maintenance nightmare. 

- similar problem with lv_status_byname_req_t, lv_req_t and 
  lv_status_byindex_req_t: They are missing "ushort size" in kernel.



Jan

  parent reply	other threads:[~2000-09-01 11:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-29  7:18 [linux-lvm] Strange Ulf Bartelt
2000-08-29 16:22 ` [linux-lvm] Dazed & Confused Andreas Dilger
2000-08-29 18:32   ` [linux-lvm] rpm Jan Niehusmann
     [not found]     ` <200009010540.XAA04818@lynx.turbolabs.com>
2000-09-01 11:29       ` Jan Niehusmann [this message]
2000-09-01 11:47         ` [linux-lvm] Re: lvm.h kernel/userspace differences Jan Niehusmann
2000-09-01 17:53         ` Andreas Dilger
2000-08-31 18:15   ` [linux-lvm] Dazed & Confused Marcelo Tosatti
2000-09-01  8:01     ` Andreas Dilger
2000-08-29 17:58 ` [linux-lvm] Strange Nils Juergens
2000-08-30  7:08   ` Ulf Bartelt
2000-09-01  8:25     ` Andreas Dilger

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=20000901132936.A3526@gondor.com \
    --to=jan@gondor.com \
    --cc=adilger@turbolinux.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.