Discussion:
[PATCH] compat-ioctl glue code to make mga_vid work for 32-bit mplayer on 64-bit kernel
Dirk Porezag
2008-09-01 21:58:41 UTC
Permalink
I'm using 32-bit mplayer with a 64-bit amd64 kernel on Debian testing, kernel 2.6.26. The current SVN mga_vid kernel module won't work with this setup since it is missing the compat_ioctl declarations necessary for 32-bit binaries calling ioctls on a 64-bit Linux kernel. So I made a patch that provides the necessary "glue code". I'm not an expert at this but it seems that the mga_vid module is 64-bit clean already (no "long" data types etc.) and all one has to do is to provide the compat_ioctl method which then calls the native mga_vid_ioctl in turn. I have tested this successfully with the Debian testing 2.6.26-1-amd64 kernel and since the changes are fairly simple most other kernels should work the same. Patch is against the SVN version of mga_vid.c (2008-08-02).

Hope this is useful,
Dirk


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfÃŒgt ÃŒber einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
Attila Kinali
2008-09-05 09:02:45 UTC
Permalink
On Mon, 1 Sep 2008 14:58:41 -0700 (PDT)
+static long mga_vid_compat_ioctl (struct file *file, unsigned int cmd,
+ unsigned long arg) {
+ long ret= 0;
+ lock_kernel();
+ ret= (long) mga_vid_ioctl((struct inode *) NULL, file, cmd, arg);
+ unlock_kernel();
+ return ret;
Is there any specific reason why you use here the BKL or
locking at all?

Attila Kinali
--
A strange game.
The only winning move is not to play.
-- Joshua, WarGames
Dirk Porezag
2008-09-05 19:38:08 UTC
Permalink
Hi Attila,
Nope, no specific reason. The reasoning for putting it in was:
- I didn't delve into the rest of the module code too deeply so I don't have a good enough idea about potential race conditions there
- according to some sources on the web, classical ioctl used to run within the BKL and of lot of compat_ioctl conversion examples that I've seen used the BKL around the wrapped ioctl call
- the ioctl rate produced by mplayer seems to be fairly low, performance with and without the lock was practically identical in my tests
So I picked the "better be safe than sorry" approach. I really should have made a note in the source stating that I wasn't sure that the BKL was necessary.

In fact, I've run a version without the BKL without any problems for some time but I figured that a single CPU single person test is not a good test for race condition safeness. To wrap it up, if you're confident the locking isn't necessary, I'm quite happy with removing it.

Dirk



----- Ursprüngliche Mail ----
Von: Attila Kinali <***@kinali.ch>
An: MPlayer on Matrox graphics cards <mplayer-***@mplayerhq.hu>
Gesendet: Freitag, den 5. September 2008, 11:02:45 Uhr
Betreff: Re: [MPlayer-matrox] [PATCH] compat-ioctl glue code to make mga_vid work for 32-bit mplayer on 64-bit kernel

On Mon, 1 Sep 2008 14:58:41 -0700 (PDT)
+static long mga_vid_compat_ioctl (struct file *file, unsigned int cmd,
+ unsigned long arg) {
+ long ret= 0;
+ lock_kernel();
+ ret= (long) mga_vid_ioctl((struct inode *) NULL, file, cmd, arg);
+ unlock_kernel();
+ return ret;
Is there any specific reason why you use here the BKL or
locking at all?

Attila Kinali
--
A strange game.
The only winning move is not to play.
-- Joshua, WarGames
_______________________________________________
MPlayer-matrox mailing list
MPlayer-***@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-matrox


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
Loading...