tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fixing tap(4) behaviour



On Wed, Dec 03, 2008 at 04:50:14PM -0500, Arnaud Lacombe wrote:
> Hi,
> 
> On Sat, Nov 29, 2008 at 4:41 PM, Quentin Garnier <cube%cubidou.net@localhost> 
> wrote:
> >> Beside that, this do not solve the problem of the behavior of the
> >> stat(2) syscall on a cloner device.
> >
> > Right.  I was pointing out that the premise for the work was incorrect,
> > which doesn't mean the work itself isn't useful.  One thing to note,
> > though, is that it is a bad idea to derive the name of the interface
> > from the unit number, because we might want to make it possible to
> > change interface names in the future,
> The name isn't derived from the unit number, but the interface index
> is derived from the device's minor. The current code already use this
> "hack" to get the interface softc when accessed through /dev/tapN. The
> major/minor -> name association belong to userland.

No, it actually belongs to the kernel, along with a devfs
implementation.  The driver is in control of the minor namespace, not
userland.  But I see your point;  currently the information is defined
in two places independently, and it only works as long as the two agree.

> > which means the network interface name and the device name might differ.
> >
> device name yes, major/minor no, cf above.

But what matters is the network interface (i.e., struct ifnet) name.

> > Which is why TAPGIFNAME takes an
> > ifreq, which is something you can actually feed to a socket ioctl
> > afterwards.
> >
> this is just YAITDI[0] :-) but I'm not sure why a program using tap(4)
> would use a socket. In general case, it opens the cloner device and
> read/write through it.

Because the only thing it needs the name for is to configure the network
interface, which you do through socket ioctls with ifreqs.  I really
don't see any other possible use for the name of the interface.

If your idea is that a process can open /dev/tap and then expect another
process to open /dev/tapN to perform concurrent work, it's definitely
the wrong way to do that.

-- 
Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpE0kG7yTPaR.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index