Results 1 to 1 of 1
Hi everybody, Does someone has a clue what has been the purpose of adding a second parameter to the USB stack function "usb_submit_urb()" in kernel 2.6? Below is an example ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 11-21-2006 #1
adding memory flags to USB stack functions in kernel 2.6
Does someone has a clue what has been the purpose of adding a second parameter to the USB stack function "usb_submit_urb()" in kernel 2.6?
Below is an example from the devolo HomePlug driver with the source file "devolo_usb.c":
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0))
if ((res = usb_submit_urb (devolo->rx_urb,GFP_KERNEL/*GFP_ATOMIC??*/)))
if ((res = usb_submit_urb (devolo->rx_urb)))
As you see, to the function "usb_submit_urb()" has been added a kernel memory flag as second parameter.
As you can also see, the developer was not sure about what flag to use.
Generally, you should use GFP_ATOMIC in interrupt context or in process context where it is not allowed to sleep, and GFP_KERNEL elsewhere.
With GFP_ATOMIC, you ask for memory from a small pool that is available immediately, or you'll get an error message, and GFP_KERNEL may take some time to look for memory elsewhere.
But it looks like, that this only theoretically a simple issue. I found also the following comment on this Web site http://lists.metaprl.org/pipermail/c...er/000025.html:
"lAso note that in lab 1 and lab 2, it would have been arguably better to
use GFP_KERNEL instead of GFP_ATOMIC. GFP_ATOMIC should be saved for
those instances in which a sleep would be totally unacceptable.
This is a fuzzy issue though...there's no absolute right or wrong
My question is now, what was the purpose to make this part of kernel programming, i.e. using the function "usb_submir_urb()", more compilcated and probably more error-prone? Is it performance? Has it to do with newly introduced real time functionalities?
Bus Error: Passengers dumped. Hech gap yo'q.