[linux-lvm] A Caldera related bug?

[linux-lvm] A Caldera related bug?

[dan_mcmanus]

Hello,

First off, if I'm not supposed to send this to you, I apologize. I am
running Caldera Openlinux workstation 3.1 with a kernel of 2.4.8 that has
LVM support enabled. My computer is a gateway 4200 Pentium II, if you care
about that. I tried this with lvm 1.0.1-rc1, 1.0, and 0.9, following the
instructions faithfully. What happens is I type "make" (after having typed
"./configure", of course) and this same error happens in each case:

[root@co1432 1.0.1-rc1]# make
make[1]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[2]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[3]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
gcc -c -pipe -g -O2 -Wall -DDEBUG -I../../tools/lib -I../../tools -o
basename.o basename.c
In file included from /usr/include/linux/prefetch.h:13,
                 from /usr/include/linux/list.h:6,
                 from ../../tools/lib/lvm.h:115,
                 from ../../tools/lib/liblvm.h:96,
                 from basename.c:34:
/usr/include/asm/processor.h:46: parse error before `u16'
/usr/include/asm/processor.h:46: warning: no semicolon at end of struct or
union
/usr/include/asm/processor.h:55: parse error before `}'
make[3]: *** [basename.o] Error 1
make[3]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[2]: Entering directory
`/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[3]: Entering directory
`/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[3]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[2]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
gcc -c -pipe -g -O2 -Wall -DDEBUG -I../tools/lib -I../tools -o e2fsadm.o
e2fsadm.c
In file included from /usr/include/linux/prefetch.h:13,
                 from /usr/include/linux/list.h:6,
                 from ../tools/lib/lvm.h:115,
                 from ../tools/lib/liblvm.h:96,
                 from ../tools/lvm_user.h:41,
                 from e2fsadm.c:53:
/usr/include/asm/processor.h:46: parse error before `u16'
/usr/include/asm/processor.h:46: warning: no semicolon at end of struct or
union
/usr/include/asm/processor.h:55: parse error before `}'
make[2]: *** [e2fsadm.o] Error 1
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[1]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1'

**********************************
There were errors in your compile.
**********************************

make[1]: *** [.touchbuilt] Error 1
make[1]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1'
make: *** [all] Error 2


Any help would be appreciated.

Thanks,

Dan McManus

Re: [linux-lvm] A Caldera related bug?

[Christoph Hellwig]

On Wed, Aug 29, 2001 at 05:04:01PM -0600, dan_mcmanus@co.blm.gov wrote:
> Hello,
> 
> First off, if I'm not supposed to send this to you, I apologize. I am
> running Caldera Openlinux workstation 3.1 with a kernel of 2.4.8 that has
> LVM support enabled. My computer is a gateway 4200 Pentium II, if you care
> about that. I tried this with lvm 1.0.1-rc1, 1.0, and 0.9, following the
> instructions faithfully. What happens is I type "make" (after having typed
> "./configure", of course) and this same error happens in each case:

This is because LVM is _completly_ broken by including kernel headers all
over theplace, and - even worse - sometimes even defining __KERNEL__ and
using kernel-only datatypes.

In fact any system using 2.4.2-ac and newer headers in /usr/include/linux
makes LVM fail this way.

I've attached the workaround I have in my RPM.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

--- LVM/1.0.1-rc1/kernel/lvm.h~	Thu Aug 30 09:00:30 2001
+++ LVM/1.0.1-rc1/kernel/lvm.h	Thu Aug 30 09:02:47 2001
@@ -110,10 +110,7 @@
 #include <linux/kdev_t.h>
 #include <linux/list.h>
 #else
-#define __KERNEL__
 #include <linux/kdev_t.h>
-#include <linux/list.h>
-#undef __KERNEL__
 #endif				/* #ifndef __KERNEL__ */
 
 #include <asm/types.h>
@@ -420,7 +417,11 @@
 
 /* remap physical sector/rdev pairs including hash */
 typedef struct lv_block_exception_v1 {
+#ifdef __KERNEL__
 	struct list_head hash;
+#else
+	uint64_t hash;			/* XXX b0rken on 64bit plattforms */
+#endif
 	uint32_t rsector_org;
 	kdev_t   rdev_org;
 	uint32_t rsector_new;

Re: [linux-lvm] A Caldera related bug?

[Andreas Dilger]

On Aug 30, 2001  09:08 +0200, Christoph Hellwig wrote:
> This is because LVM is _completly_ broken by including kernel headers all
> over theplace, and - even worse - sometimes even defining __KERNEL__ and
> using kernel-only datatypes.

Yes, it is going to be ugly when kdev_t is no longer == dev_t.

> --- LVM/1.0.1-rc1/kernel/lvm.h~	Thu Aug 30 09:00:30 2001
> +++ LVM/1.0.1-rc1/kernel/lvm.h	Thu Aug 30 09:02:47 2001
> @@ -110,10 +110,7 @@
>  #include <linux/kdev_t.h>
>  #include <linux/list.h>
>  #else
> -#define __KERNEL__
>  #include <linux/kdev_t.h>
> -#include <linux/list.h>
> -#undef __KERNEL__
>  #endif				/* #ifndef __KERNEL__ */

In this case, you may as well just remove the whole "#ifdef __KERNEL__"
part of the header here.

>  /* remap physical sector/rdev pairs including hash */
>  typedef struct lv_block_exception_v1 {
> +#ifdef __KERNEL__
>  	struct list_head hash;
> +#else
> +	uint64_t hash;			/* XXX b0rken on 64bit plattforms */
> +#endif

Maybe the non-kernel part can be considered as two void * pointers?
I'm not sure if that will work on sparc64, if the kernel and user
pointer sizes are not the same.

In the end, what is really needed is a well-defined LVM API between
kernel and user-space that doesn't pass this kind of stuff.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] A Caldera related bug?

[Patrick Caulfield]

On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> 
> >  /* remap physical sector/rdev pairs including hash */
> >  typedef struct lv_block_exception_v1 {
> > +#ifdef __KERNEL__
> >  	struct list_head hash;
> > +#else
> > +	uint64_t hash;			/* XXX b0rken on 64bit plattforms */
> > +#endif
> 
> Maybe the non-kernel part can be considered as two void * pointers?
> I'm not sure if that will work on sparc64, if the kernel and user
> pointer sizes are not the same.

It should be OK because the ioctl32 layer fixes it up anyway.

Patrick

Re: [linux-lvm] A Caldera related bug?

[Christoph Hellwig]

On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> On Aug 30, 2001  09:08 +0200, Christoph Hellwig wrote:
> > This is because LVM is _completly_ broken by including kernel headers all
> > over theplace, and - even worse - sometimes even defining __KERNEL__ and
> > using kernel-only datatypes.
> 
> Yes, it is going to be ugly when kdev_t is no longer == dev_t.

It's not only ugly, it's _broken_.  This means the LVM ABI changes
because of a kernel-internal change.

> 
> > --- LVM/1.0.1-rc1/kernel/lvm.h~	Thu Aug 30 09:00:30 2001
> > +++ LVM/1.0.1-rc1/kernel/lvm.h	Thu Aug 30 09:02:47 2001
> > @@ -110,10 +110,7 @@
> >  #include <linux/kdev_t.h>
> >  #include <linux/list.h>
> >  #else
> > -#define __KERNEL__
> >  #include <linux/kdev_t.h>
> > -#include <linux/list.h>
> > -#undef __KERNEL__
> >  #endif				/* #ifndef __KERNEL__ */
> 
> In this case, you may as well just remove the whole "#ifdef __KERNEL__"
> part of the header here.

It's not that easy.  I still need linux/list.h in case of __KERNEL__.
Maybe the following is better:

#include <linux/kdev_t.h>
#ifdef __KERNEL__
# include <linux/list.h>
#endif

> 
> >  /* remap physical sector/rdev pairs including hash */
> >  typedef struct lv_block_exception_v1 {
> > +#ifdef __KERNEL__
> >  	struct list_head hash;
> > +#else
> > +	uint64_t hash;			/* XXX b0rken on 64bit plattforms */
> > +#endif
> 
> Maybe the non-kernel part can be considered as two void * pointers?
> I'm not sure if that will work on sparc64, if the kernel and user
> pointer sizes are not the same.

I could be made work with the current sparc ioctl translation layer.
I doubt anyone actually wants to do that with the ever-changing LVM
APIs.

> In the end, what is really needed is a well-defined LVM API between
> kernel and user-space that doesn't pass this kind of stuff.

Completly agreed.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [linux-lvm] A Caldera related bug?

[Joe Thornber]

On Thu, Aug 30, 2001 at 11:46:13AM +0200, Christoph Hellwig wrote:
> On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> > In the end, what is really needed is a well-defined LVM API between
> > kernel and user-space that doesn't pass this kind of stuff.
> 
> Completly agreed.

I think every one is aware of this, but we can't change the interface during
the 2.4 series.  If you're interested check out the LVM2 module and look
at the code in driver/device-mapper (dm.h is a good intro).

- Joe

Re: [linux-lvm] A Caldera related bug?

[Christoph Hellwig]

On Thu, Aug 30, 2001 at 12:09:29PM +0100, Joe Thornber wrote:
> On Thu, Aug 30, 2001 at 11:46:13AM +0200, Christoph Hellwig wrote:
> > On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> > > In the end, what is really needed is a well-defined LVM API between
> > > kernel and user-space that doesn't pass this kind of stuff.
> > 
> > Completly agreed.
> 
> I think every one is aware of this, but we can't change the interface during
> the 2.4 series.

Well, you change it all over the time..
IMHO replacing all these kernel types in the structures also used by the
tools to others that have the same size but do not depend on kernel headers
would be a very good thing for 1.0.2.

> If you're interested check out the LVM2 module and look
> at the code in driver/device-mapper (dm.h is a good intro).

Yes, this looks very promising.  Not for the near future, though.

	Christoph

Re: [linux-lvm] A Caldera related bug?

[Joe Thornber]

On Thu, Aug 30, 2001 at 02:16:31PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 30, 2001 at 12:09:29PM +0100, Joe Thornber wrote:
> > On Thu, Aug 30, 2001 at 11:46:13AM +0200, Christoph Hellwig wrote:
> > > On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> > > > In the end, what is really needed is a well-defined LVM API between
> > > > kernel and user-space that doesn't pass this kind of stuff.
> > > 
> > > Completly agreed.
> > 
> > I think every one is aware of this, but we can't change the interface during
> > the 2.4 series.
> 
> Well, you change it all over the time..
> IMHO replacing all these kernel types in the structures also used by the
> tools to others that have the same size but do not depend on kernel headers
> would be a very good thing for 1.0.2.

ok, I'll look at them.  I can't see how we can get rid of the kdev_t's
though.

> 
> > If you're interested check out the LVM2 module and look
> > at the code in driver/device-mapper (dm.h is a good intro).
> 
> Yes, this looks very promising.  Not for the near future, though.

Well it shouldn't take too long to get the tools working with the new
driver (a few weeks).  I'm really waiting for approval from
linux-kernel before committing time to this though.

- Joe

Re: [linux-lvm] A Caldera related bug?

[Christoph Hellwig]

On Thu, Aug 30, 2001 at 04:03:48PM +0100, Joe Thornber wrote:
> On Thu, Aug 30, 2001 at 02:16:31PM +0200, Christoph Hellwig wrote:
> > On Thu, Aug 30, 2001 at 12:09:29PM +0100, Joe Thornber wrote:
> > > On Thu, Aug 30, 2001 at 11:46:13AM +0200, Christoph Hellwig wrote:
> > > > On Thu, Aug 30, 2001 at 03:23:21AM -0600, Andreas Dilger wrote:
> > > > > In the end, what is really needed is a well-defined LVM API between
> > > > > kernel and user-space that doesn't pass this kind of stuff.
> > > > 
> > > > Completly agreed.
> > > 
> > > I think every one is aware of this, but we can't change the interface during
> > > the 2.4 series.
> > 
> > Well, you change it all over the time..
> > IMHO replacing all these kernel types in the structures also used by the
> > tools to others that have the same size but do not depend on kernel headers
> > would be a very good thing for 1.0.2.
> 
> ok, I'll look at them.  I can't see how we can get rid of the kdev_t's
> though.

#ifdef __KERNEL__
#include <linux/kdev_t.h>
typedef kdev_t lvm_dev_t;
#else
typedef uint16_t lvm_dev_t;
#endif

and s/kdev_t/lvm_dev_t/g in lvm.h.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

[linux-lvm] A Caldera related bug?

[dan_mcmanus]

Hello,

Please disregard my previous message. I have figured out what to do to make
it compile, namely copying over the /usr/include/linux directory that had
the files from the old kernel and replacing them with those from the new
kernel ( /usr/src/linux/include ). And viola, it worked. Thanks anyway,

Dan McManus

Previous message follows:
__________________

Hello,

First off, if I'm not supposed to send this to you, I apologize. I am
running Caldera Openlinux workstation 3.1 with a kernel of 2.4.8 that has
LVM support enabled. My computer is a gateway 4200 Pentium II, if you care
about that. I tried this with lvm 1.0.1-rc1, 1.0, and 0.9, following the
instructions faithfully. What happens is I type "make" (after having typed
"./configure", of course) and this same error happens in each case:

[root@co1432 1.0.1-rc1]# make
make[1]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[2]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[3]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
gcc -c -pipe -g -O2 -Wall -DDEBUG -I../../tools/lib -I../../tools -o
basename.o basename.c
In file included from /usr/include/linux/prefetch.h:13,
                 from /usr/include/linux/list.h:6,
                 from ../../tools/lib/lvm.h:115,
                 from ../../tools/lib/liblvm.h:96,
                 from basename.c:34:
/usr/include/asm/processor.h:46: parse error before `u16'
/usr/include/asm/processor.h:46: warning: no semicolon at end of struct or
union
/usr/include/asm/processor.h:55: parse error before `}'
make[3]: *** [basename.o] Error 1
make[3]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/lib'
make[2]: Entering directory
`/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[3]: Entering directory
`/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[3]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools/man8'
make[2]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
gcc -c -pipe -g -O2 -Wall -DDEBUG -I../tools/lib -I../tools -o e2fsadm.o
e2fsadm.c
In file included from /usr/include/linux/prefetch.h:13,
                 from /usr/include/linux/list.h:6,
                 from ../tools/lib/lvm.h:115,
                 from ../tools/lib/liblvm.h:96,
                 from ../tools/lvm_user.h:41,
                 from e2fsadm.c:53:
/usr/include/asm/processor.h:46: parse error before `u16'
/usr/include/asm/processor.h:46: warning: no semicolon at end of struct or
union
/usr/include/asm/processor.h:55: parse error before `}'
make[2]: *** [e2fsadm.o] Error 1
make[2]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1/tools'
make[1]: Entering directory `/usr/src/linux/extras/LVM/1.0.1-rc1'

**********************************
There were errors in your compile.
**********************************

make[1]: *** [.touchbuilt] Error 1
make[1]: Leaving directory `/usr/src/linux/extras/LVM/1.0.1-rc1'
make: *** [all] Error 2


Any help would be appreciated.

Thanks,

Dan McManus