search for: lowerdev

...oes not have IFF_SLAVE should be looked at. Are you saying that's not the right thing to do and userspace should be fixed? What should userspace do in your opinion that will be forward compatible with future kernels? > > >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. > > Each master type has a IFF_ master flag and IFF_ slave flag. Could you give some examples please? > In private > flag. I don't see no reason to break this pattern here. Other masters are setup from userspace, this one is set up automatically by kernel. So the bar is higher,...

...oes not have IFF_SLAVE should be looked at. Are you saying that's not the right thing to do and userspace should be fixed? What should userspace do in your opinion that will be forward compatible with future kernels? > > >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. > > Each master type has a IFF_ master flag and IFF_ slave flag. Could you give some examples please? > In private > flag. I don't see no reason to break this pattern here. Other masters are setup from userspace, this one is set up automatically by kernel. So the bar is higher,...

...ould be looked at, nothing else. > > > >to do and userspace should be fixed? What should userspace do in > >your opinion that will be forward compatible with future kernels? > > > >> > >> >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. > >> > >> Each master type has a IFF_ master flag and IFF_ slave flag. > > > >Could you give some examples please? > > enum netdev_priv_flags { > IFF_EBRIDGE = 1<<1, > IFF_BRIDGE_PORT = 1<<9...

...ould be looked at, nothing else. > > > >to do and userspace should be fixed? What should userspace do in > >your opinion that will be forward compatible with future kernels? > > > >> > >> >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. > >> > >> Each master type has a IFF_ master flag and IFF_ slave flag. > > > >Could you give some examples please? > > enum netdev_priv_flags { > IFF_EBRIDGE = 1<<1, > IFF_BRIDGE_PORT = 1<<9...

...m it's sufficiently like a bond slave for IFF_SLAVE to make sense. In fact you will find that netvsc already sets IFF_SLAVE, and so does e.g. the eql driver. The advantage of using IFF_SLAVE is that userspace knows to skip it. If we don't set IFF_SLAVE existing userspace tries to use the lowerdev. -- MST

...m it's sufficiently like a bond slave for IFF_SLAVE to make sense. In fact you will find that netvsc already sets IFF_SLAVE, and so does e.g. the eql driver. The advantage of using IFF_SLAVE is that userspace knows to skip it. If we don't set IFF_SLAVE existing userspace tries to use the lowerdev. -- MST

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

...FLA_MASTER is the attribute that should be looked at, nothing else. >to do and userspace should be fixed? What should userspace do in >your opinion that will be forward compatible with future kernels? > >> >> >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. >> >> Each master type has a IFF_ master flag and IFF_ slave flag. > >Could you give some examples please? enum netdev_priv_flags { IFF_EBRIDGE = 1<<1, IFF_BRIDGE_PORT = 1<<9, IFF_OPENVSWITCH...

...lse. >> >> >> >to do and userspace should be fixed? What should userspace do in >> >your opinion that will be forward compatible with future kernels? >> > >> >> >> >> >we don't set IFF_SLAVE existing userspace tries to use the lowerdev. >> >> >> >> Each master type has a IFF_ master flag and IFF_ slave flag. >> > >> >Could you give some examples please? >> >> enum netdev_priv_flags { >> IFF_EBRIDGE = 1<<1, >> IFF_BRIDGE_P...

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this