Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
> 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, );
if (err) break;
}
}
}
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
