Pavel Emelianov wrote:
Ben Greear wrote:
[snip]
I would also like some way to identify veth from other device types,
preferably
something like a value in sysfs. However, that should not hold up
We can do this with ethtool. It can get and print the driver name of
the device.
I think I'd like something in sysfs that we could query for any
interface. Possible return
strings could be:
VLAN
VETH
ETH
PPP
BRIDGE
AP /* wifi access point interface */
STA /* wifi station */
....
I will cook up a patch for consideration after veth goes in.
Ben, could you please tell what sysfs features do you
plan to implement?
I think this is the only thing that has a chance of getting into the kernel.
Basically, I have a user-space app and I want to be able to definitively
know the type for
all interfaces. Currently, I have a hodge-podge of logic to query
various ioctls and /proc
files and finally, guess by name if nothing else works. There must be a
better way :P
I have another sysfs patch that allows setting a default skb->mark for
an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one
has very little chance
of getting into the kernel. The skb->mark patch is only useful (as far
as I can tell) if you
also include a patch Patrick McHardy did for me that allowed the
conn-tracking logic to
use skb->mark as part of it's tuple. This allows me to do NAT between
virtual routers
(routing tables) on the same machine using veth-equivalent drivers to
connect the
routers. He thinks this will probably not ever get into the kernel either.
I have another sysctl related send-to-self patch that also has little
chance of getting into the kernel, but
it might be quite useful with veth (it's useful to me..but my needs
aren't exactly mainstream :))
I'll post this separately for consideration....
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
