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
next prev 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.