if your question means that intended driver should not interface with a real
ethernet hardware, then the answer is that it perfectly possible for driver
to register itself as a ethernet driver to io-net but not send/recieve from
actual hardware.

from qnx perspective, it is like any other driver with top proto being "en"
and lower protocol being "NULL".

If however you want you driver to recieve directly IP packets from stack,
you can init io-net with external_arp option and register your driver as a
convertor module that has IP on top and ethernet at bottom. In which case
your module will get all the IP packets and will be responsible for finding
the mac address of next hop...

hope this helps

VG

On Sun, Mar 20, 2011 at 5:16 PM, Max Timchenko <community-noreply@qnx.com>wrote:

> I couldn't find any examples of such a thing, but it could be useful for
> some virtual drivers that are not really Ethernet in nature for which
> wrapping and unwrapping the packets in Ethernet headers is merely
> unnecessary overhead.
>
> I assume such a driver couldn't use struct ethercom and the corresponding
> ether_* methods. What would replace them? Is it possible to use tun sources
> as a reference to how this could be implemented?
>
> An example would be perfect, but even a pointer in the direction of a
> solution would be appreciated.
>
> Thanks, Max
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post84114
>
>