Re: [Xen-devel] modifying drivers

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

On Sat, 2010-02-20 at 18:10 -0500, Ritu kaur wrote:
> Thanks Daniel and Pasi. However, I have followup questions
> 
> 1. Daniel, I looked at Debian Etch 4.0 source code available from
> Citrix website, couldn't find netfront specific code, could you please
> point me to the right one.

Source should be drivers/xen/netfront. Should all reside in the debian
etch dom0 kernel package distributed with XCP. It's obviously not a
source RPM, but a debian source package (dsc, orig, etc). Is this the
source you're already looking at?

> 2. Since netfront in domU actually monitors "ethX" interface and when
> ethX is used for transmit(via ping or other network protocols) it
> invokes network_start_xmit which then uses shared memory rings to
> communicate to backend and uses netif_poll to check for responses. In
> struct netfront_info_, it has a field struct net_device *netdev, and
> entry points are hooked to this
> 
>     netdev->open            = network_open;
>         netdev->hard_start_xmit = network_start_xmit;
>         netdev->stop            = network_close;
>         netdev->get_stats       = network_get_stats;
>         netdev->poll            = netif_poll;
>         netdev->set_multicast_list = network_set_multicast_list;
>         netdev->uninit          = netif_uninit;
> ...
> 
> Since netback has similar code, I will not go into it.
> 
> I looked at struct net_device, it has a function ptr called "do_ioctl"
> and I wanted to know if this can be used for out ioctl need i.e 
> 
> 1. setup netdev->do_ioctl = network_ioctl
> 2. application invokes ioctl(eth2(associated with our intf in
> backend), ...)
> 3. network_ioctl is called and it does similar to xmit and recv via
> shared memory.
> 
> is this feasible? 

This would be the entry point for a socket ioctl, yes. It's feasible.
Not with right away with the present source code. But strictly speaking
such a thing can certainly be made.

I'd suggest not to try piggybacking this kind of operation on some RX/TX
traffic, or defining new message types. It won't really fit in there.

It would much rather turn into a third I/O ring. Assuming the control
data volume transferred between domain justifies it. Please don't
understand this as some kind of recommendation.

Daniel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel