Messages in this thread | | | Subject | NT DDK vs. Linux DDI, a practical comparison [long] | Date | Sat, 19 Sep 1998 22:43:12 -0700 | From | Stephen Williams <> |
| |
alex.buell@tahallah.demon.co.uk said: > Do you find that the Linux device driver interfaces a lot cleaner than > the NT device driver interfaces? I'm genuinely curious to know.
No comparison. NT is positively hideous. It is amazing how amateurish the NT kernel mode interface is. However, for your viewing pleasure, I include a driver for our ISE board in order to demonstrate my reasoning. The source supports Linux and NT, so you can see side-by-side the Linux and NT version of the same thing. Judge for yourself. It is possible that I need educating. (Please!)
Note that the NT version may not be perfect. It is extremely difficult to get memory that a process and a device can share under NT, my hack may only work on NT/intel, not NT/alpha. NT/Intel support has been well tested by now, but my alpha has become too important to me to actually run the NT system I have installed.
Linux/Intel and Linux/alpha are fairly bullet-proof.
NT needs UDI much more then Linux does:-)
Here it is: <ftp://ftp.picturel.com/pub/source/ucr/driver.tgz>
BIG NOTE! NT kernel mode is *different* from UNIX kernel mode. Where the UNIX driver model is process/thread based, the NT driver interface is event based, with events (such as read request, cancels, etc.) being passed through a common dispatch routine. The thinking engineer will not blame NT for simply being different. My opinions are based on technical experience and *my judgments* of what is technically important. Keep an open and just mind. Be practical, we are *not* bigots.
OBSERVATIONS:
NT has no equivalent to pcibios_find_device et. al. Each device driver is expected to scan the PCI bus to locate its devices. The DriverEntry function in winnt.c does this function. This is normal when dealing with ISA devices (I've not been so blessed) and has not been updated to support the auto- configuring bus architectures of the '90s.
There have been a lot of people in the ntdev mailing list complaining that HalAssignSlotResources has been rearranging PCI devices, and botching it. This driver gets the information from the device and uses an alternate (documented) means of finding things. In fact, I read stuff directly from the PCI configuration space of the target device. This works fine under NT, and Linux. NT programmers, take note.
HalTranslateBusAddress will go berserk on NT/Intel if there are two ISE boards. (The PCI interface is implemented by Intel i960RD chips.) It also seems to fail completely on other perfectly valid PCI devices. I have no explanation. NT can be coerced into functioning, but the odds of this coersion working on anything other then Intel are slim. There is the occasional board that I just can't seem to access under NT, that works fine under Linux. Ideas?
(See winntdev.c line 679.)
There is no "printk" under NT. There is the event logger, which is fine as far as it goes, but after a while you start having nightmares in UNICODE; so I wrote a printk replacement whose outputs can be read from a virtual device, and this is my best debugging tool. It turns out that there is a tool to display DbgPrint messages, but that function is compiled out in the "free" (meaning optimized) build.
Linux lacks a practical way to get large, physically contiguous regions of memory. NT wins here, although this device doesn't need it. Better devices don't need it, but occasionally you have good reason to be cheap and the lack of scatter-gather hurts under Linux. I'll be pushing the bygphysarea patch once 2.3 starts.
In fact, getting large amounts of memory under Linux is painful. 1/2 points for NT. (*IF* there is any memory left after the NT kernel takes it all:-)
NT completely lacks anything like mmap support. Video devices have a different interface that doesn't seem to intersect with the read/write interface that I also require, so heck. I found a roundabout way to do it--it's scary, but it works. It is not a general solution. This is surprising, because you can mmap files under NT. It turns out that file mapping is implemented by the file system and never gets down to the driver.
NT will provide for you mapped and locked pages of the process buffer for reads and writes. This allows one to DMA directly into the process buffer if you write the driver (and device) to support it. You get a Mdl, which you are supposed to pass to the DMA handling code. It is not clear how this works for PCI devices, but I haven't put much effort into it. Some Linux driver writers have been pining for such a capability.
Linux's lax use of unsigned long to hold pointers is a little distressing, though it has worked to date, thanks to the sensible GNU compiler. NT has the PHYSICAL_ADDRESS type which is even worse.
NT/alpha does not work as advertised, especially when trying to write to memory-mapped PCI registers. HalTranslateBusAddress does not do the intuitive thing on a PC164. Burned one of my allotted 2 calls/year on this feature. Save your chit, memory type 6 (undocumented) is sparse memory mapped registers and MmMapIoSpace is *not* to be used:-/
NT has no module autoloader. Or unloader. You can explicitly load a driver, or unload it, but nothing will figure it out for you. It most certainly can *not* handle modules (*.sys files) referencing other modules. Linux is light-years ahead here.
You can't synchronize with interrupts under NT, you must start a DPC and synchronize with that. Under Linux you would expect to be able to do a wakeup() in an ISR. In fact I try to avoid cli() under Linux by disabling interrupts at the board. This works almost all the time, but occasionally I get to the point where the driver must wait for a signal from the ISR. See winntsync.c for how wakeup gets implemented in NT.
The Linux equivilent of the DPC is the ISR top half (or is it bottom half, I forget.) I rarely bother.
And so on. I'm available for further questioning if the subject of NT vs. Linux interests you. I've done my share. Source code available.
-- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com But I have promises to keep, steve@picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |