Re: compat ioctl32 for /dev/snapshot?

[Michael Tokarev]

Pavel Machek wrote:
> On Mon 2009-05-04 13:29:22, Michael Tokarev wrote:
> > Is there any reason why 32-bit uswsusp &Friends does not work
> > on 64bits kernel?
> >
> > For one, 32bits s2disk produces the following when trying to
> > suspend:
> >
> >  ioctl32(s2disk:4134): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} arg(ff853554) on /dev/snapshot
> >  ioctl32(s2disk:4134): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000805) on /dev/snapshot
> >
> > this is coming from:
> >
> >     error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
> >     if (error && !offset)
> >             error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
> >
> > but I guess (just guess!) that other SNAPSHOT_* operations will
> > also fail the same way.
> >
> > Is there a reason why those are not in compat_ioctl?
>
> Lazyness...?
>
> Patch would be welcome.

Pavel, you really should take a look at the original thread.

As I mentioned in my first email, I'm not the right person to
do the patch.  But regardless, I spent about a day understanding
this stuff (or trying to, anyway) - 100% useless day - and when
I thought I have a patch someone else spoken up and said this
way (compat_ioctl) is the wrong approach now.  And sent another,
also trivial patch, adding compat calls right to the proper
place in kernel/power.c.  Which (the patch) has been ignored
too.

So "welcome" is a wrong word here, and I'm sorry about that.

> On 4GB machine, running 64bit kernel (but
> staying with 32bit userland) makes sense...

This is exactly what I'm running here by the way.
But regardless, uswsusp should be fixed too before it will
be useful for that.  And fixing uswsusp is not trivial,
unlike kernel side.  But having in mind amount of useless
jumping needed just for the trivial kernel part, for a
20-minute patch, -- there's not much hope really.  (I
wanted to fix it too, initially, -- not any more).

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