Re: LVM / General IOCTL question

On Thu, 13 Nov 2003, Dean Anderson wrote:

> I'm trying to get LVM to work on aurora, and find that I can't seem to get
> the proper ioctls to work:
> 
> LVM version 1.0.5+(22/07/2002) module loaded
> sys32_ioctl(pvcreate:6228): Unknown cmd fd(3) cmd(c004fe06) arg(effff614)
> sys32_ioctl(pvcreate:6228): Unknown cmd fd(3) cmd(4004fe98) arg(effff6e6)
> 
> This message seems to be a result of sys32_ioctl not finding the results
> of COMPATIBLE_IOCTL(LVM_GET_IOP_VERSION) in ioctl32.c...
> 
> Strangely, this is only compiled in if the kernel is completely recompiled
> with the CONFIG_BLK_DEV_LVM_MODULE flag, which kind of defeats the whole
> idea of modules... but I'll leave that alone for now.

That does seem a bit strange, yes...

> My real question is, after searching this out, I find a whole bunch of
> ioctl translation stuff in the module independent parts of the kernel.  I
> see some wrong assumptions in this (mainly that IOCTL numbers are not
> globally unique)

Where does it make that assumption?

> but wondered if someone can clue me in on what the idea is with doing
> translations.  It seems that all that is being done is fix up structures
> which have pointers embedded in them.  But of course, this could also be
> done by the userspace code that uses the structures coming out of the
> kernel, which seems (to my way of thinking anyway) a much, much better
> place to do this.

Userspace is running 32-bit, kernel is running 64-bit.  For most things,
the pointer just goes to an integral value, not a structure, so you can
just you can just translate the pointer and pass a value through, but some
things need more sophisticated translation.  COMPATIBLE_IOCTL() is saying
"you can just futz with the pointer for me", HANDLE_IOCTL() is saying "the
args here are complicated, and we built a special function which
translates the values", and they build a table of how to handle each
ioctl.

> This seems to be such a terrible clusterf*ck, creating a lot of update
> contention on a ioctl32.c. But of course, we'll also ignore/acknowledge
> that sending pointers out of the kernel is probably also a clusterf*ck
> waiting to happen.

Not just a clusterfuck.  You actually _can't_ do it, because the pointers
aren't the same as userland's.

> However, this just seems to make it worse, rather than better.

It makes it possible.

--
        Peter

I hope you know that this will go on your permanent record.

_______________________________________________
Aurora-sparc-devel mailing list
[email protected]
http://lists.auroralinux.org/mailman/listinfo/aurora-sparc-devel
Aurora FAQ: http://www.ecs.soton.ac.uk/~mas01r/aurorafaq.html