aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/compat_ioctl.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2005-11-16[DVB]: Add compat ioctl handling.David S. Miller1-0/+67
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-12[SPARC]: Fix RTC compat ioctl kernel log spam.Christoph Hellwig1-0/+8
On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote: > > This change: > > diff-tree 8ca2bdc7a98b9584ac5f640761501405154171c7 (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-09[PATCH] fbdev: move ioctl32 code to fbmem.cArnd Bergmann1-7/+0
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[PATCH] move some COMPATIBLE_IOCTL entries from x86_64 to common codeChristoph Hellwig1-0/+8
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-07-04[SPARC64/COMPAT]: Add some compat ioctl for ppdevRaphael Assenat1-1/+18
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-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+771
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!