Re: [uml-devel] Q: UML thread communication - scheduling oddness

[Jeff Dike <jdike@addtoit.com>]

gmarzot@nortelnetworks.com said:
> Could you add a few sentences though on the delivery mechnisms for the
>  the packets to the kernel thread and to userspace. I saw a poll() on
> the  pollfds array which has the taps fd in it but this is a
> non-blocking  poll and I could not trace to how often it is called and
> what triggers  it - I also saw the sigio handler but I could not see
> who was generating  the SIGIO - is that how the userspace thread is
> woken up? 

OK, an incoming packet is handled this way:
	it's received by the host and routed to the tap device (or 
alternatively, it's received by the host eth, sent to the bridge that it's part
of, and copied to the tap device which is also in the bridge)
	it pops out of /dev/net/tun, which UML has a file descriptor open to
	the file descriptor is set up O_ASYNC, so that generates a SIGIO
	this causes sigio_handler to be called
	it looks at all of the descriptors in its care, and handles all the
ones that are now active
	the network driver's interrupt routine is called whenever a tap fd is
active, and it reads the frame off the fd and passes it to the UML network 
stack

sigio_handler does blocking polls because it knows that something is active,
and that it won't, in fact, block.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel