Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at
>    <http://www.sistina.com/>
> for download (Follow the "LVM download page" link).

Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Would it be possible to clean up the ioctl interface so we dont need
such large hacks for LVM support? I can do the work but I want to be
sure you guys will agree to it.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

   <http://www.sistina.com/>

for download (Follow the "LVM download page" link).


This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for further information.

We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
patch to Linus.

Please test and feed back related information to <linux-lvm@sistina.com>.

Thanks a lot for your support of LVM.

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Andreas Dilger]

Anton, you write:
> Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Yuk.

> Would it be possible to clean up the ioctl interface so we dont need
> such large hacks for LVM support? I can do the work but I want to be
> sure you guys will agree to it.

What is the reason for all this?  Alignment/wordsize/other?  If you look
at the IOP10 code, much of the in-core data structs were changed to int
or long, so this sparc code may not be necessary.  It may in fact be
damaging, because I don't know if any of the LVM developers even know it
is there, and surely it will be out of sync...

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.  It may in fact be
> damaging, because I don't know if any of the LVM developers even know it
> is there, and surely it will be out of sync...

Two things:

Structures used in ioctls should have explicit sizes (eg u32, not unsigned
long). Remember on sparc64 we have a 32 bit userspace and 64 bit kernel.

Having pointers to other structures is considered bad form again due to the
32bit/64bit differences. Think 32 bit pointers vs 64 bit pointers :)

When either of these happen we have to write up translation code. Of
the two, having pointers to other structs is definitely the worst. 

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> Anton, you write:
> > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> 
> Yuk.
> 
> > Would it be possible to clean up the ioctl interface so we dont need
> > such large hacks for LVM support? I can do the work but I want to be
> > sure you guys will agree to it.
> 
> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.

The longs are the biggest problem AFAICS.
long is 64bit on sparc64 and 32bit on sparc32...

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

Embedding pointers in ioctls is much worse. When this happens we basically
end up duplicating the ioctl parsing code (this code courtesy of jakub's
sharp mind, but it would be nice not to require this :)

Anton

        case VG_CREATE:
                v = kmalloc(sizeof(vg_t), GFP_KERNEL);
                if (!v) return -ENOMEM;
                if (copy_from_user(v, (void *)arg, (long)&((vg32_t *)0)->proc) ||
                    __get_user(v->proc, &((vg32_t *)arg)->proc)) {
                        kfree(v);
                        return -EFAULT;
                }
                karg = v;
                memset(v->pv, 0, sizeof(v->pv) + sizeof(v->lv));
                if (v->pv_max > ABS_MAX_PV || v->lv_max > ABS_MAX_LV)
                        return -EPERM;
                for (i = 0; i < v->pv_max; i++) {
                        err = __get_user(ptr, &((vg32_t *)arg)->pv[i]);
                        if (err) break;
                        if (ptr) {
                                v->pv[i] = kmalloc(sizeof(pv_t), GFP_KERNEL);
                                if (!v->pv[i]) {
                                        err = -ENOMEM;
                                        break;
                                }
                                err = copy_from_user(v->pv[i], (void *)A(ptr), sizeof(pv32_t) - 8);
                                if (err) {
                                        err = -EFAULT;
                                        break;
                                }
                                v->pv[i]->pe = NULL; v->pv[i]->inode = NULL;
                        }
                }
                if (!err) {
                        for (i = 0; i < v->lv_max; i++) {
                                err = __get_user(ptr, &((vg32_t *)arg)->lv[i]);
                                if (err) break;
                                if (ptr) {
                                        v->lv[i] = get_lv_t(ptr, &err);
                                        if (err) break;
                                }
                        }
                }
                break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Patrick Caulfield]

On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > Anton, you write:
> > > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> > 
> > Yuk.
> > 
> > > Would it be possible to clean up the ioctl interface so we dont need
> > > such large hacks for LVM support? I can do the work but I want to be
> > > sure you guys will agree to it.

If you're prepared to do the work we'd be glad to accept the patch - please send
it to me or the list so I can check over it before committing it. As we don't
have an UltraSPARC available for testing it's probably better done by someone
who does !
 
> > What is the reason for all this?  Alignment/wordsize/other?  If you look
> > at the IOP10 code, much of the in-core data structs were changed to int
> > or long, so this sparc code may not be necessary.
> 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

There are still a few ulong members in lvm.h, they should be uint32_t 

patrick

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/