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)
Oct 15 2024, 2:59 PM
Unknown Object (File)
Oct 5 2024, 6:52 PM
Unknown Object (File)
Oct 2 2024, 5:34 AM
Unknown Object (File)
Sep 8 2024, 1:44 AM
Unknown Object (File)
Sep 7 2024, 11:00 AM
Unknown Object (File)
Aug 24 2024, 4:55 AM
Unknown Object (File)
Aug 23 2024, 5:56 AM
Unknown Object (File)
Aug 21 2024, 5:45 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.