Arnd Bergmann wrote:
- The return value of the new compat_ioctl methods should probably
'int', not 'long'. We've had the discussion before and then
decided not to change the existing compat_ioctl and
unlocked_ioctl functions -- even though int is more appropriate,
but having the same prototype has the advantage that a driver
can use the same function for both ->ioctl and ->compat_ioctl
if all calls are compatible.
I noticed that but thought the change in return value type
had some higher purpose I had not perceived. If it can be int
that would be the way to go.
- In your driver you don't get the big kernel lock in the
compat_ioctl function. I assume that this is correct for
the particular driver, but it may be nice if you could
consequently also add an unlocked_ioctl function that can
be used without the BKL for native ioctls. It would be good
to hear an opinon on this from someone who has an insight
in tty locking issues though, so I'm Cc:ing some people
who have touched that recently.
I don't count on higher level locking for
synchronization issues specific to the driver.
I thought the current compat_ioctl() was already
meant to *not* have the BKL just like unlocked_ioctl.
My thought was that any driver getting a recent update
like compat_ioctl() would need to be reviewed for BKL
safety and take the lock manually if necessary.
Drivers that are falling behind wont have a compat_ioctl
defined at all.
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
