Linux Device Driver Unsafe Fxsave/Fxrstor Bug - Any Precedents

What are coding conventions for using floating-point in Linux device drivers?

Short answer: Kernel code can use floating point if this use is surrounded by kernel_fpu_begin()/kernel_fpu_end(). These function handle saving and restoring the fpu context. Also, they call preempt_disable()/preempt_enable(), which means no sleeping, page faults etc. in the code between those functions. Google the function names for more information.

If I understand correctly, whenever a
KM is running, it is using a hardware
context (or hardware thread or
register set -- whatever you want to
call it) that has been preempted from
some application thread.

No, a kernel module can run in user context as well (eg. when userspace calls syscalls on a device provided by the KM). It has, however, no relation to the float issue.

If you write your KM in c, the
compiler will correctly insure that
the general-purpose registers are
properly saved and restored (much as
in an application), but that doesn't
automatically happen with
floating-point registers.

That is not because of the compiler, but because of the kernel context-switching code.

How can 2 wireless interfaces be handled by single carl9170 device driver module

For 2, take a look at the folder:

drivers/net/wireless/ath/carl9170/

This folder is located under your kernel source directory. It contains all the sources of the driver.

For 1:

It is pretty much how classes works on oriented object programming: how does an object know which instance of the data it must work with? The this pointer references the correct in memory data.

Take a look at the file drivers/net/wireless/ath/carl9170/carl9170.h. Every function exported by the driver is declared at this file. Note that every function has at its first parameter a reference to the struct ar9170 data type. This is exactly the data set that the driver must work with. It specifies everything the driver need to know about the device and its sates, since the USB buses address where the device is connected, to the state of the device, like its power, connection state and any other data the driver itself need in order to keep the device working properly.

Note that this is driver internal data thought. The kernel has its own set of data to keep both the driver, the device and the kernel itself working.

Take a look at the 546 line of carl9170.h. It is where the function declarations starts. This file is as of the kernel 3.8.8.

Just like in Object Oriented Programming you would allocate as many instances of a class as you need, the kernel will allocate as many ar9170 structures a it needs, one referencing each device.

The device ids can be obtained under the /sys/class/net directory. There will be a soft link for each of the network devices attached to your computer. This link will point the device to something like the following:

$ ls -l eth0
../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0

The pci0000:00 is the bus. The 0000:00:04.0 I believe is the bus address. Finally, the 0000:02:00.0 is the device id. Afaik, every registered device follows the same logic.

Finally, if you have two carl9170 devices, both will be under the directory /sys/class/net but probably one of them will be named wifi0 and the other wifi1. Also, each of them will point to different devices (check it with the command ls -l /sys/class/net).

I just would like to note that in the explanation I haven't used any wireless card. So I'm not sure whether wireless cards are shown under /sys/class/net or not. Anyway, it will be something very similar, like /sys/class/wireless.

Related Topics