From: Ben Greear <greearb@candelatech.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Patrick McHardy <kaber@trash.net>,
Stephen Hemminger <shemminger@linux-foundation.org>,
Mark Lord <lkml@rtr.ca>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
containers@lists.osdl.org, David Miller <davem@davemloft.net>
Subject: Re: namespace support requires network modules to say "GPL"
Date: Tue, 04 Dec 2007 10:57:01 -0800 [thread overview]
Message-ID: <4755A2FD.9020608@candelatech.com> (raw)
In-Reply-To: <m18x4axrx2.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>
>>> Regardless of infringement it is incompatible with a complete network
>>> namespace implementation. Further it sounds like the module you are
>>> describing defines a kernel ABI without being merged and hopes that
>>> ABI will still be supportable in the future. Honestly I think doing so
>>> is horrible code maintenance policy.
>>>
>>>
>> I don't mind if the ABI changes, so long as I can still use something similar.
>>
>
> It has occurred to me that I am seeing an implication here that may in fact not
> exist.
>
> My impression of dev_get_by_xxxx is that the function is only able to be used
> sanely when being part of the definition of a kernel/userspace interface. With
> the further assumption on my part that you need to define a new instance of
> dev_get_by_xxxx
>
> It has just occurred to me that it is possible to reuse the SIOCBRADDIF
> and SIOCBRDELIF for that same purpose without defining a new kernel/userspace
> interface.
>
> What and how are you using dev_get_by_xxx?
>
I have a module that has a collection of 2-port bridges. These bridges
are used for emulation
purposes (somewhat similar to netem's feature set). Each bridge is
logically independent
of the others. To set up a bridge, I do something like:
echo add_my_bridge my_br1 eth0 eth1 > /proc/net/foo/config
Inside the module, it reads "eth0" and "eth1" and needs to find those
devices (ie, dev_get_by_name). It then registers to receive all pkts from
eth1 and transmit them on eth0, and vice versa.
If it would not require GPL symbols, I have no problem changing my API
to be something
like:
echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY >
/proc/net/foo/config
I am using procfs so that I don't have to define any new 'official'
kernel ABI, as that would more likely be a derivative work, and is a pain
to keep up to date with changing kernels anyway...
Personally, it seems useful for my module to be able to have eth0 in one
namespace
and eth1 in another, but I won't complain if they both have to be in the
same namespace
or even just in the default namespace due to GPL symbol issues.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2007-12-04 18:57 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-01 9:06 [PATCH 0/10] sysfs network namespace support Eric W. Biederman
2007-12-01 9:12 ` [PATCH 01/10] sysfs: Make sysfs_mount static again Eric W. Biederman
2007-12-01 9:13 ` [PATCH 02/10] sysfs: Support for preventing unmounts Eric W. Biederman
2007-12-01 9:16 ` [PATCH 03/10] sysfs: sysfs_get_dentry add a sb parameter Eric W. Biederman
2007-12-01 9:18 ` [PATCH 04/10] sysfs: Implement __sysfs_get_dentry Eric W. Biederman
2007-12-01 9:23 ` [PATCH 05/10] sysfs: Rename Support multiple superblocks Eric W. Biederman
2007-12-01 9:25 ` [PATCH 06/10] sysfs: sysfs_chmod_file handle " Eric W. Biederman
2007-12-01 9:28 ` [PATCH 07/10] sysfs: Implement sysfs tagged directory support Eric W. Biederman
2007-12-01 9:30 ` [PATCH 08/10] sysfs: Implement sysfs_delete_link and sysfs_rename_link Eric W. Biederman
2007-12-01 9:33 ` [PATCH 09/10] driver core: Implement tagged directory support for device classes Eric W. Biederman
2007-12-01 9:35 ` [PATCH 10/10] net: Enable tagging for net_class directories in sysfs Eric W. Biederman
2007-12-01 13:10 ` namespace support requires network modules to say "GPL" Mark Lord
2007-12-01 13:13 ` Mark Lord
2007-12-01 19:17 ` Stephen Hemminger
2007-12-01 19:23 ` Alan Cox
[not found] ` <20071201192341.6750fbdb-v58gJUvfdfWUJIigds3554dd74u8MsAO@public.gmane.org>
2007-12-01 19:38 ` Stephen Hemminger
2007-12-01 19:45 ` Alan Cox
2007-12-01 20:13 ` Eric W. Biederman
[not found] ` <m13aum5g1x.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-12-01 20:21 ` Mark Lord
2007-12-01 20:29 ` Arjan van de Ven
2007-12-01 22:12 ` Mark Lord
2007-12-01 23:13 ` Eric W. Biederman
2007-12-01 23:24 ` Jiri Slaby
2007-12-02 1:14 ` Eric W. Biederman
2007-12-01 23:51 ` Mark Lord
2007-12-02 1:08 ` Eric W. Biederman
2007-12-01 20:52 ` Eric W. Biederman
2007-12-01 22:13 ` Mark Lord
2007-12-03 0:02 ` David Schwartz
2007-12-03 0:14 ` Alan Cox
2007-12-01 19:54 ` Eric W. Biederman
2007-12-02 0:30 ` Stephen Hemminger
2007-12-02 2:02 ` Eric W. Biederman
2007-12-02 3:34 ` Mark Lord
2007-12-02 4:23 ` Stephen Hemminger
2007-12-02 19:28 ` Ben Greear
2007-12-02 20:03 ` Patrick McHardy
2007-12-02 20:43 ` Adrian Bunk
2007-12-02 21:59 ` Patrick McHardy
2007-12-03 1:14 ` Adrian Bunk
2007-12-03 8:33 ` Denis V. Lunev
2007-12-03 17:35 ` Eric W. Biederman
2007-12-03 18:19 ` Ben Greear
2007-12-03 18:57 ` Daniel Lezcano
2007-12-04 15:19 ` Daniel Lezcano
2007-12-04 18:03 ` Eric W. Biederman
2007-12-04 18:44 ` Ben Greear
2007-12-04 19:17 ` Eric W. Biederman
2007-12-04 19:35 ` Ben Greear
2007-12-04 20:09 ` Eric W. Biederman
2007-12-05 6:14 ` David Miller
2007-12-05 6:01 ` David Miller
2007-12-04 17:59 ` Eric W. Biederman
2007-12-04 18:57 ` Ben Greear [this message]
2007-12-04 20:01 ` Eric W. Biederman
2007-12-05 6:07 ` David Miller
2007-12-03 8:24 ` Romano Giannetti
2007-12-03 15:34 ` Arjan van de Ven
2007-12-03 18:03 ` Eric W. Biederman
2007-12-03 18:13 ` David Miller
2007-12-02 13:51 ` Alan Cox
2007-12-02 19:56 ` Valdis.Kletnieks
2007-12-21 3:07 ` [PATCH 0/10] sysfs network namespace support Greg KH
2007-12-21 13:04 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4755A2FD.9020608@candelatech.com \
--to=greearb@candelatech.com \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).