Messages in this thread | | | Subject | Re: NT DDK vs. Linux DDI, a practical comparison [long] | Date | Sun, 20 Sep 1998 11:34:07 -0700 | From | Stephen Williams <> |
| |
Thank you for your comments.
chaffee@cs.berkeley.edu said: > I'm confused by this. DbgPrint works fine in non-checked build.
You are of course right. There is a macro version that wraps it and can be compiled out. I forgot about that because I had long since wrote the "isecons" virtual device to handle debug messages.
There is also a tool on (maybe the same tool, contributed to) the ntinternals web page. I have tried it, but found that the way I've done it allows the customer to turn on and view debug messages on my driver without any third party tools.
chaffee@cs.berkeley.edu said: > I have a routine in the driver called MapMemory that takes physical > memory on the PCI bus and maps it into a user mode process's address > space. Maybe this isn't what you are talking.
Right. Under Linux I was able to allocate pages with get_free_page (no need to keep them contiguous) then tell the board where the pages are; and use nopage to map them into a process. This creates shared memory between the process and the board that does not already have that memory. The ISE board hads scads of image memory for processing image data, but it is faster to access shared host memory then to share the on-board memory.
Under NT, the best I could figure out what to allocate a physically contiguous frame and use ZwMapViewOfSection to map \Device\PhysicalMemory (the NT equivilent of /dev/mem) for the process. This means that I must allocate a single, large, physically contiguous buffer under NT where lots of pages will do under Linux.
Another technique people use is to have the process send a DeviceIoControl IRP that passes a large buffer by reference, and is not completed. One can grab the Mdl from that, get the physical addresses, and there. However, I wanted my frames to persist. Handling the death of that magic process would have been equally painful.
There is no hook that allows an NT driver to participate in demand paging.
chaffee@cs.berkeley.edu said: > Not quite true. You can create modules that reference other modules.
You can stack modules a la streams. The IRP for a request is then passed through the stack of devices, just like streams. However, the NT kernel does not automatically notice that module X is needed, and there is no kerneld to bring it in. Nor do they get cleaned up when the references are dropped.
Under Linux, modules can export symbols, and with a little help from depmod you can have the kernel linking modules on demand, and unlinking when it is done. This is just too darn slick. -- 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/
| |