Commit Graph

6 Commits

Author SHA1 Message Date
David S. Miller
6e87abd0b8 [DVB]: Add compat ioctl handling.
Based upon a patch by Guido Guenther <agx@sigxcpu.org>.

Some of these ioctls had embedded time_t objects
or pointers, so needed translation.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-16 00:52:57 -08:00
Christoph Hellwig
535f8d65d8 [SPARC]: Fix RTC compat ioctl kernel log spam.
On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote:
> 
> This change:
> 
> diff-tree 8ca2bdc7a9 (from feee207e44d3643d19e648aAuthor: Christoph Hellwig <hch@lst.de>
> Date:   Wed Nov 9 12:07:18 2005 -0800
> 
>     [SPARC] sbus rtc: implement ->compat_ioctl
>     
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> results in the console now getting spewed on sparc64 systems
> with messages like:
> 
> [   11.968298] ioctl32(hwclock:464): Unknown cmd fd(3) cmd(401c7014){00} arg(efc
> What's happening is hwclock tries first the SBUS rtc device ioctls
> then the normal rtc driver ones.
> 
> So things actually worked better when we had the SBUS rtc compat ioctl
> directly handled via the generic compat ioctl code.
> 
> There are _so_ many rtc drivers in the kernel implementing the
> generic rtc ioctls that I don't think putting a ->compat_ioctl
> into all of them to fix this problem is feasible.  Unless we
> write a single rtc_compat_ioctl(), export it to modules, and hook
> it into all of those somehow.
> 
> But even that doesn't appear to have any pretty implementation.
> 
> Any better ideas?

We had similar problems with other ioctls where userspace did things
like that.  What we did there was to put the compat handler to generic
code.  The patch below does that, adding a big comment about what's
going on and removing the COMPAT_IOCTL entires for these on powerpc
that not only weren't ever useful but are duplicated now aswell.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-12 12:10:54 -08:00
Arnd Bergmann
c7f82d9c49 [PATCH] fbdev: move ioctl32 code to fbmem.c
The frame buffer layer already had some code dealing with compat ioctls, this
patch moves over the remaining code from fs/compat_ioctl.c

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-09 07:56:36 -08:00
Christoph Hellwig
b05a581d48 [PATCH] move some COMPATIBLE_IOCTL entries from x86_64 to common code
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-09 07:56:01 -08:00
Raphael Assenat
e7270dec08 [SPARC64/COMPAT]: Add some compat ioctl for ppdev
The following patch adds some ioctls to include/linux/compat_ioctl.h
to allow using ppdev from the 32 bit user space on sparc64.

This patch also adds the PPDEV option in the sparc64 menu, near Parallel
printer support in the 'General machine setup' submenu.

All those ioctls seem to be compatible, since (correct me if I'm wrong)
they dont use the 'long' type. See include/linux/ppdev.h.

The application I used to test the new ioctls only used the following:
PPEXCL
PPCLAIM
PPNEGOT
PPGETMODES
PPRCONTROL
PPWCONTROL
PPDATADIR
PPWDATA
PPRDATA

But I beleive that the other ioctls will work fine.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-04 13:23:45 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00