Re: [Xen-devel] modifying drivers

Daniel Stodden
Sun, 21 Feb 2010 21:35:22 -0000

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