Hello Jakub, On Monday, 02.10.2017 at 12:49, Jakub Jermář wrote: > I have a functional Intel gigabit (wm) rump kernel to the extent that I > can ping it and play with it as long as there is the TCP/IP stack and > sockets sitting on top of it. This is all nice, but I would like to make > it a much smaller component that only includes the wm driver and > provides ethernet frames to other components in the host system.
+1, having a canonical way of using low-level interface drivers without needing the higher-level parts of the stack would be a useful thing to have. Recently I had a conversation about this exact same scenario with Adrian Rueegsegger (of the Muen SK project), so I'm looping him into Cc: on this thread (Adrian: Not sure if you're subscribed to the list). > I was initially thinking of replacing parts of the TCP/IP stack with my > own code involving things such as direct invocation of ifq_enqueue() and > registering a soft interrupt for receiving packets), but that turned out > to be a very intrusive thing, a rump kernel anti-pattern I would say. > For example, as the definition of struct mbuf is not public for use in > rump kernel clients, I would have to somehow redefine it in order to be > able to use these interfaces. I abandoned this effort because of that. > > Instead, I focused only on being able to get ethernet frames in and out > of the driver for now. I implemented the virtif hyperinterface for the > host system and created a virtual bridge between the wm device and the > virtual interface. While not being a minimal solution (the TCP/IP stack > is still there and packets need to travel through more interfaces), I am > at least able to interface the virtual NIC in a clean way. > > I was wondering if someone has already done something similar. Is there > a recommended, canonical way of achieving my goals? Would you also use > the virtual bridge and virtual interface if you were implementing this? > My ideal solution would probably be to provide wm's own hyperinterface, > similar to that of libvirtif. The TCP/IP stack would be just one > implementation of this interface and it would be possible to create > alternative ones so that one does not have to bother with the bridge and > virtual interface and could also get rid of the rest of the stack. That seems like a reasonable approach to me. I don't have any specific technical recommendations to make beyond that, but there are others on this list who have a better understanding of where to best make the cut in terms of the internal NetBSD APIs and rump component boundaries. It will be interesting to see how much more of the base components could be stripped from such a setup -- e.g. doing away with the socket/syscall parts entirely, though that might just be wishful thinking on my part. -mato
