Hi all,
Can you tell what is ccx certification. I know that it is
given by CISCO on meeting standards. What are the minimum qualification
to obtain the certification.We
need to get the certificate for printer device that supports WLAN?
Thanks& Regards
-Hari
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Sunday, December 02, 2007 9:44 PM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Difference between Scatter/Gather DMA and Common
Buffer DMA
Actually, I have a third solution, and I have used it over and again
during my professional life. The solution is, write to the hardware
standard and achieve compatibility at processor level, underneath and in
spite of the OS.
Use the API when you have to talk to the OS, but do not allow the OS to
interpose itself between driver and hardware. Drivers handle i/o
hardware:
OS’s shouldn’t.
Works wonders!
I do not support IA64, so, I don’t have to bother about it. But the
differences between i386 and amd64 are rather small, and it’s easy to
handle them at run time. And if the APIC isn’t there, my polling loop
will catch the interrupts anyway. The OS-independent part of my driver,
that’s about 75% of the code, works on both processors on all the OS’s I
support. The Windows OS-dependent code works on both 32-bit and 64-bit
systems, and, believe me, it’s the same source code.
About “supported”, the only level of support I recognize in my device
driver is that which I give to my customers. I do not need any other
kind of support except an OS API that’s guaranteed to work if and when I
exercise it. In my opinion, the best OS is the unobtrusive one, which I
take for granted and don’t need to remember it exists!
Alberto.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, December 01, 2007 10:29 PM
Subject: RE:[ntdev] Difference between Scatter/Gather DMA and Common
Buffer DMA
> Alberto,
>
>> The problem with using the NT DMA API is that it binds the driver to
>> Windows.
>> That can be a rather undesirable thing, for example, in my case
>> where I need to make sure that most of my DMA runs just the same
>> under Windows, Linux, Solaris and MacOS.
>
> Unfortunately, there is no such thing as an absolute portability -
> your have to choose between hardware portability and software
> portability…
>
> You have 2 options here:
>
> 1. Write your code the way OS designers tell you to. If you do it this
> way, your source-level version of a driver for the system X may be
> very different from the one for the system Y, but at least you will
> be able to use the same source for building drivers for every hardware
> platform that the target OS supports.
>
> 2. Ignore the system-provided API altogether, and do everything
yourself.
> If you do it this way, you will be able to use the same source for
> building drivers for every OS that runs on the target hardware
platform.
> However, you have to write separate versions of a driver for every
> hardware platform the target OSes may run on. For example, your
> solution with custom MSI is not going to work if the target machine
> does not support APIC, and there are still quite of few of these
> machines around ( I already don’t mention the fact that you have to
> write separate versions of a driver for x86, x64 and IA64)
>
>
> In other words, you have to choose between cross-hardware and cross-OS
> portability - there is no way to build drivers for every hardware and
> software platform in existence from the same source. In practical
> terms, it is much easier to write separate “supported” versions of a
> driver for few well-known OSes, rather than to write separate
> “unsupported” versions of a driver for every hardware platform in
existence…
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer