unlocked_ioctl vs normalnej ioctl

Question

W file_operations struktury mojego kierowcy, mam:

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

Tj nie ma użytego pola ioctl. Czy to wystarcza, aby uniknąć Big Kernel Lock i wejść do device_ioctl() bez jakiejkolwiek synchronizacji? Czy muszę również zmieniać wywołania funkcji ioctl() w części przestrzeni użytkownika?

Answer 1

Uhm, rozwiązałem to. Wymagana jest również zmiana sygnatury funkcji device_ioctl. Nie ma parametru i-węzła, a także funkcja powinna zwracać się długo. Podobnie jak w następujących patch:

-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) 
{ 

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

Answer 2

przeczytać ten artykuł LWN: http://lwn.net/Articles/119652/

też kiedyś między 2.6.33 i 6.2.35 RC (użyj git-diff aby dowiedzieć się, które zatwierdzenie) jądro jest teraz WARNs, gdy zdefiniowana jest tylko .ioctl.

Jest to krok w kierunku bardziej wyraźnego i drobnoziarnistego blokowania. Zwróć też uwagę tylko na zmianę sygnatury funkcji i wskaźnika, ale wprowadzi możliwość warunków wyścigu (dwie aplikacje przestrzeni użytkownika wykonujące jednocześnie wywołania ioctl).

Answer 3

Andi Kleem napisali przepis na szybki i brzydka konwersji kodu przy użyciu ioctl do unlocked_ioctl na Linux listy jądra:

[JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl

Przepis wyjaśnia, w jaki sposób dostosować parametry tej funkcji, i wstawić zamek i odblokowywanie połączeń.