unlocked_ioctl vs ioctl normales

Question

En la estructura file_operations de conducir, tengo:

struct file_operations Fops = {
  read:    device_read,
  write:   device_write,
  unlocked_ioctl:   device_ioctl,
  ...
};

es decir. no hay ningún campo ioctl utilizado. ¿Es esto suficiente para evitar grandes Kernel Lock y entrar en device_ioctl () sin ningún tipo de sincronización? O tengo que cambiar ioctl () llama en la parte de espacio de usuario del código también?

Answer 1

Uhm, resolvió este. También es necesario para cambiar la firma de la función device_ioctl. No existe ningún parámetro i-nodo, y también la función debe devolver larga. Al igual que en el siguiente parche:

-static int st_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd_in, unsigned long arg)
+static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
{

(de: http://linux.derkeiler.com /Mailing-Lists/Kernel/2008-01/msg06799.html )

Answer 2

Lee este artículo LWN: http://lwn.net/Articles/119652/

También en algún momento entre 2.6.33 y 2.6.35 un rc (uso git-diff para averiguar que practican) el kernel ahora avisa cuando se define solamente .ioctl.

Este es un movimiento hacia bloqueo de forma más explícita y de grano fino. También tenga en cuenta solamente el cambio de la firma de la función y el puntero se compilará pero introducirá la posibilidad de condiciones de carrera (dos aplicaciones de espacio de usuario haciendo llamadas ioctl al mismo tiempo).

Answer 3

Andi Kleem registró una receta para una conversión rápida y sucia de código usando ioctl a unlocked_ioctl en Linux lista de correo del kernel:

[JANITOR PROPUESTA] funciones de conmutación a ioctl -> unlocked_ioctl

La receta explica cómo ajustar los parámetros de la función y de inserción de bloqueo y desbloqueo de llamadas.