Alexey Kuznetsov [EMAIL PROTECTED] writes:
Hello!
Good point, I didn't think of that. Is there a version of this patch
that already uses different namespaces so I can look at it?
Pavel does not like the idea. It looks not exactly pretty, like you said.
:-)
The alternative is to create
Eric W. Biederman wrote:
Reading through the patches they look usable to me.
Having to patch iproute to create the more interesting network
devices sucks, but that problem seems fundamental. We might
be able to avoid it if we allowed fields to be reused between
different types of devices
Patrick McHardy wrote:
The following patches contain the rtnetlink link creation API I promised,
as well as two simple driver conversion to use the API as an example.
I've also converted VLAN as a more complex example, but these patches
need some more work and are most likely not interesting
Patrick McHardy [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Reading through the patches they look usable to me.
Having to patch iproute to create the more interesting network
devices sucks, but that problem seems fundamental. We might
be able to avoid it if we allowed fields to be
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
You don't really need to patch it, installing a new iplink_XXX.so
file is enough. Generalizing driver specific options more than
what we currently have doesn't look very promising. I think your
driver was simple enough to get
Hello!
I just suggested to
Pavel to create only a single device per newlink operation and binding
them later,
I see some logical inconsistency here.
Look, the second end is supposed to be in another namespace.
It will have identity, which cannot
Patrick McHardy [EMAIL PROTECTED] writes:
I still think adding a IFLA_PARTNER or a custom attribute is cleaner
in this case. Slight semantic mismatches are the worst design bugs
to correct.
Indeed, IFLA_PARTNER sounds like a better idea. I just suggested to
Pavel to create only a single
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
I still think adding a IFLA_PARTNER or a custom attribute is cleaner
in this case. Slight semantic mismatches are the worst design bugs
to correct.
Indeed, IFLA_PARTNER sounds like a better idea. I just suggested to
Pavel
Alexey Kuznetsov wrote:
I just suggested to
Pavel to create only a single device per newlink operation and binding
them later,
I see some logical inconsistency here.
Look, the second end is supposed to be in another namespace.
It will have
Patrick McHardy [EMAIL PROTECTED] writes:
Alexey Kuznetsov wrote:
I just suggested to
Pavel to create only a single device per newlink operation and binding
them later,
I see some logical inconsistency here.
Look, the second end is supposed
Hello!
Good point, I didn't think of that. Is there a version of this patch
that already uses different namespaces so I can look at it?
Pavel does not like the idea. It looks not exactly pretty, like you said. :-)
The alternative is to create pair in main namespace and then move
one end to
The following patches contain the rtnetlink link creation API I promised,
as well as two simple driver conversion to use the API as an example.
I've also converted VLAN as a more complex example, but these patches
need some more work and are most likely not interesting to all the CCed
parties, so
From: Patrick McHardy [EMAIL PROTECTED]
Date: Tue, 5 Jun 2007 16:12:51 +0200 (MEST)
A few words about the API:
Drivers wishing to use the API register a struct rtnl_link_ops, which
contains a few function pointers for device setup, registation, changing
and deletion, as well as netlink
David Miller wrote:
From: Patrick McHardy [EMAIL PROTECTED]
Date: Tue, 5 Jun 2007 16:12:51 +0200 (MEST)
A few words about the API:
[..]
Not sure what else to say .. comments welcome.
This excellent description of the APIs (particularly the background
and reasoning) belongs in a file
All patches looked really good. speaking for the ifb stuff, a definete
ACK.
The only thing that threw me off for a sec was the naming convention for
type referenced via IFLA_INFO_NAME because it seems to be colliding
semantic with dev-type and dev-name as in IFLA_NAME and
ifi_type ifinfomsg.
jamal wrote:
All patches looked really good. speaking for the ifb stuff, a definete
ACK.
The only thing that threw me off for a sec was the naming convention for
type referenced via IFLA_INFO_NAME because it seems to be colliding
semantic with dev-type and dev-name as in IFLA_NAME and
On Wed, 2007-06-06 at 00:07 +0200, Patrick McHardy wrote:
How about IFLA_INFO_KIND (borrowed from sch_api)? I generally don't
like the IFLA_INFO_ prefix very much, but so far didn't come up with
something better. Suggestions welcome :)
KIND sounds a lot more tasty ;- Thanks.
cheers,
jamal
-
Reading through the patches they look usable to me.
Having to patch iproute to create the more interesting network
devices sucks, but that problem seems fundamental. We might
be able to avoid it if we allowed fields to be reused between
different types of devices but that makes the error
18 matches
Mail list logo
