bhyve: add support for ng_device network backend

[quentin.thebault_defenso.fr]

Summary

Signed-off-by: Quentin Thébault <[e-mail]>
Sponsored by: Defenso

[markj]

The bhyve.8 man page needs to be updated to mention the new backend.

usr.sbin/bhyve/net_backends.c

123

The && should be on the previous line.

[quentin.thebault_defenso.fr]

Added bhyve.8 changes and fixed if syntax.

[quentin.thebault_defenso.fr]

usr.sbin/bhyve/net_backends.c

123

Done, thank you.

[quentin.thebault_defenso.fr]

Removed superfluous Xo and Xc in bhyve.8

[markj]

tap_init() will open the device and add it to the mevent loop, which uses kevent() under the hood. But, ng_device doesn't implement d_kqfilter, i.e., ngd_cdevsw doesn't have a d_kqfilter implementation, in contrast with tap devices. How does bhyve know when to read packets from the device?

usr.sbin/bhyve/bhyve.8

551

New sentences should start on new lines.

[quentin.thebault_defenso.fr]

In D52542#1201906, @markj wrote:

tap_init() will open the device and add it to the mevent loop, which uses kevent() under the hood. But, ng_device doesn't implement d_kqfilter, i.e., ngd_cdevsw doesn't have a d_kqfilter implementation, in contrast with tap devices. How does bhyve know when to read packets from the device?

Please have a look at parent revision D52541, which adds kevent support to ng_device.

[markj]

In D52542#1201909, @quentin.thebault_defenso.fr wrote:

In D52542#1201906, @markj wrote:

tap_init() will open the device and add it to the mevent loop, which uses kevent() under the hood. But, ng_device doesn't implement d_kqfilter, i.e., ngd_cdevsw doesn't have a d_kqfilter implementation, in contrast with tap devices. How does bhyve know when to read packets from the device?

Please have a look at parent revision D52541, which adds kevent support to ng_device.

Aha! :) I left some comments there.

This diff looks ok to me.

usr.sbin/bhyve/bhyve.8

549

[quentin.thebault_defenso.fr]

Add missing carriage return in bhyve.8

[quentin.thebault_defenso.fr]

Add reference to netgraph(4)

[markj]

This looks ok to me, but it depends on the other revision, which is as-yet unfinished.