Page MenuHomeFreeBSD

Allow an open of /dev/tap to grab an existing device that is not currently open.
Needs ReviewPublic

Authored by jhb on Jun 12 2015, 2:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jul 7, 8:52 AM
Unknown Object (File)
Mon, Jul 7, 7:30 AM
Unknown Object (File)
Sun, Jul 6, 8:20 AM
Unknown Object (File)
Sat, Jul 5, 5:12 PM
Unknown Object (File)
Thu, Jun 26, 7:41 PM
Unknown Object (File)
Tue, Jun 24, 2:16 PM
Unknown Object (File)
Jun 8 2025, 5:39 PM
Unknown Object (File)
May 12 2025, 1:10 PM
Subscribers

Details

Reviewers
None
Group Reviewers
network
Summary

Currently the devfs cloning of /dev/tap creates a new tap interface on each
open. For some applications (e.g. hypervisors) it would be nice to have an
easy way to allocate a "free" tap interface without creating a new tap
interface each time. This change adds an option (off by default) to allow
an open of /dev/tap to reuse an existing tap interface that is not open by
another device.

One caveat is that I don't see an easy way to prevent a race between another
process attempting to open /dev/tap or explicitly opening the same existing
tap interface by name. Ideally an open of /dev/tap should never fail.
Unfortunately, the devfs cloning mechanism is also invoked for non-open cases.

Test Plan
  • Run 'cat > /dev/tap' back to back and see it reuse a single tap interface vs creating a new one on each run.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage

Event Timeline

jhb retitled this revision from to Allow an open of /dev/tap to grab an existing device that is not currently open..
jhb updated this object.
jhb edited the test plan for this revision. (Show Details)
jhb added a subscriber: grehan.

The other approach we could consider which would be race-free would be to make /dev/tap a real cdev and instead of fetching the interface to open from si_drv1 on the cdev, we instead store the pointer to the softc in the cdevpriv data. We could still support /dev/tapX devices as well, though perhaps that would be a legacy option that would eventually go away?

For now I've made the new behavior opt-in, but it seems a bit useless to me as "give me a free one" is what I think most programs really want from /dev/tap.

Also, whatever approach we decide for /dev/tap can also probably be ported to /dev/tun as well.