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.
Referenced Files
Unknown Object (File)
Sep 24 2023, 12:23 AM
Unknown Object (File)
Aug 25 2023, 10:25 AM
Unknown Object (File)
Jul 5 2023, 2:46 AM
Unknown Object (File)
Apr 22 2023, 7:07 PM
Unknown Object (File)
Jul 7 2016, 11:09 AM
Unknown Object (File)
Feb 21 2016, 3:59 PM
Unknown Object (File)
Dec 19 2015, 7:39 PM
Unknown Object (File)
Dec 13 2015, 3:37 AM


Group Reviewers

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

rS FreeBSD src repository - subversion
Lint Passed
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.