lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectNT DDK vs. Linux DDI, a practical comparison [long]
Date
From

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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.218 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site