more LVM 0.8 patches

hello here are more lvm patches.
they apply over patches in lvm-0.8final-3.3.src.rpm
1st chunk is needed to compile on my system (mine only?? K6-2, kernel 2.4.0-test8, glibc 2.1.3, pgcc-2.95.3) 2nd chunk is nice for devfs
3rd chunk is NEEDED for lvm over raid

I am still missing something on the vgchange front, the binary version i saved before trashing my whole system this summer works, the one built from these sources doesn't.

Regards
L.

Luca Berra -- [email protected]
    Communication Media & Services S.r.l.

@@ -70,7 +70,10 @@
 #include <linux/major.h>
 #include <linux/genhd.h>
 
+#include <stdint.h>
+#define __KERNEL__
 #include <linux/lvm.h>
+#undef __KERNEL__
 
 #ifndef uint8_t
 #  define uint8_t	u_int8_t

@@ -59,8 +59,8 @@
    char major[20] = { 0, };
    char minor[20] = { 0, };
    char blocks[20] = { 0, };
-   char devname[30] = { 0, };
-   char procline[127] ;
+   char devname[127] = { 0, };
+   char procline[256] ;
    static char *devdir[] = {
       "/dev/ida",
       "/dev/ide/hd",

@@ -96,14 +96,18 @@
             if ( dir_cache[i].st_rdev == st_rdev)
                break;
          }
+         memset ( disk_dev_name, 0, sizeof ( disk_dev_name));
+         strncpy ( disk_dev_name, dir_cache[i].dev_name, sizeof ( disk_dev_name) - 1);
+      } else {
+         memset ( disk_dev_name, 0, sizeof ( disk_dev_name));
+         strncpy ( disk_dev_name, dev_name, sizeof ( disk_dev_name) - 1);
+
       }
    } else {
       ret = -LVM_EPV_GET_SIZE_LVM_DIR_CACHE;
       goto pv_get_size_end;
    }
 
-   memset ( disk_dev_name, 0, sizeof ( disk_dev_name));
-   strncpy ( disk_dev_name, dir_cache[i].dev_name, sizeof ( disk_dev_name) - 1);
 
    first = 1;
    if ( ( pv_handle = open ( disk_dev_name, O_RDONLY)) == -1) {

excellent...

this fixes the compile problem i had with the tools that i reported to Andreas before (but i hadn't compiled the kernel, so he asked me to do that).

successfully compiles against 2.4.0-test10-pre4, glibc-2.94, gcc-2.96.

regards,

paul jakma

Actually, this is a bit of a problem. In my 2.2 kernel patch, I include an lvm.h that can be used for both user and kernel compiles, so that you are sure you have the same IOP version, struct sizes, etc. However, this lvm.h doesn't exist on 2.4.

I have never tried using my 2.2 lvm.h header to compile the 2.4 kernel. It is mosly correct (I preserved _most_ of the 2.4 definitions and such), but that wasn't my real goal (I was interested in a 2.2 header) so I doubt it has everything.

If you are interested to do a bit of work, it would be good to take my 2.2 lvm.h and add the few missing "#if kernel 2.2 use this, #else use that" checks and I will add it into my lvm.h so it can be used by everyone.

These look OK. I will add them into my patch.

What sort of symptoms are you having (sorry if you already posted them)?

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

IMHO this is the wrong thing. Userlevel tools should not include kernel headers. IOP version mismatches are detected at run time.
In my RPMs I keep including the userlevel header and it works fine for Linux 2.2 and 2.4. The RPMs do also include most fixes by Andreas and from this list (Luca's have just been added). If anyone is interested, they can be found on

ftp.openlinux.org:/pub/people/hch/lvm/lvm-tools-0.8final-5.src.rpm ftp.openlinux.org:/pub/people/hch/lvm/lvm-tools-0.8final-5.i386.rpm (Glibc 2.1.94)

Christoph

Always remember that you are unique.  Just like everyone else.

Actually, there IS a problem that isn't addressed by the IOP version, probably because someone changed the lvm.h file after Heinz added it to the kernel. In the lv_v2 struct (in the 2.4 kernel sources) the "uint8 __unused" field was added after lv_block_exception_t, and this was not reflected in a IOP version change. This field is NOT in the lvm.h lv_v2 included in the 0.8final user tools.

That is why I chose to have a single lvm.h between user and kernel space. I know that it is bad to include linux/*.h headers in user tools, but I wanted the tools to compile properly with the header in the current kernel.

*** If we at least make the header include/linux/lvm.h and tools/lib/lvm.h
exactly the same, it will make tracking changes a lot easier. Better would be to have per-struct version numbers, or make the ioctl numbers reflect the struct sizes (which is already part of the ioctl definitions) we can track changes a lot easier, and allow backwards compatibility when struct sizes change because they will get unique ioctl numbers for the old and new interface.

Note that the user tools tarball that I have also includes the lvm.h under tools/lib, I just don't use it. At most, you will need to change #include <linux/lvm.h> to #include <lib/lvm.h> in lvm_user.h and liblvm.h.

If people agree that we should keep kernel and user headers totally separate, I will change this for my next release.

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

I will check into this eventually,
the problem is i don't work on linux full-time
so i hack into lvm whenever i have some spare time, or i am forced to do it.

just does not work, at the moment i have a single vg, and the machine boots from it, so it is very difficult to debug. I should put gdb into my initrd :)

L.

Luca Berra -- [email protected]
    Communication Media & Services S.r.l.