> What's the plan to attack 32-bit ioctls?
> ...
> but I guess that's going to cause objections?
>
> Yes, a huge dragon to slay for sure.
>
> To be honest, I'm happy with what's possible right now.
> SIOCDEVPRIVATE was the biggest problem and that can be
> gradually phased out.
>
> Let's attack the easy stuff first, then we can retry finding
> a nicer solution to the ioctl bits.
>
> There are places where real work is needed, for example emulation
> of drivers/usb/core/devio.c is nearly impossible without adding
> some code to devio.c It keeps around user pointers, and doesn't
> write to the area during that syscall but at some later time
> as the result of another system call.
Right option might be to kill devio.c :-). It has other problems, too,
IIRC.
Pavel
-- Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/