I was basically thinking to abstract those interface like : Mapping Registers, Interrupts ( with timeouts to cover the DPCforIsr etc )
without using polling etc.
Well, the task in itself is not infeasible, but implementing something like that would require developing some “Virtual PCI/PCIe” bus, plus, apparently, making certain modifications to the existing system services (IoConnectInterrupt() is the very first thing that gets into my head) in order to integrate it with the existing architecture.
The very first real-life analogy that comes to my mind here is advising Peter to invest in few oil rigs, as well as in oil refinery, at the time when the only thing he asks us about is a direction to the nearest petrol station…
Let others give practical feed back
In my opinion, Calvin’s suggestion seems to be the most reasonable one in so far. All you have to do is to get some dirt-cheap low-end network adapter. Once we are speaking about a simple class exercise, you don’t really need to think of it as of a real-life network interface that is utilised by the bound protocol drivers. Therefore, you don’t really need to expose it to NDIS.
Once you haven’t got any existing clients, apart from your test application, there are no compulsory interfaces that you are required to implement on the upper edge, which means it is up to you to decide upon the API that it exposes to its clients. Therefore, you don’t need to make use of all its potential capabilities. For the purpose of this exercise, you can think of it just as of a simple device that is capable of sending and receiving data, so that you can make it as simple as you wish.
To summarise, the key points here are wide availability, low cost, flexibility of choosing its programming model, availability of register-level documentation, as well of an open-source implementation that you may use as a potential reference…
Anton Bassov