Daniel Lezcano wrote:
Ben Greear wrote:
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a
bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
Ben Greear [EMAIL PROTECTED] 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.
Daniel Lezcano [EMAIL PROTECTED] writes:
Ben Greear wrote:
Once things are largely complete it makes sense to argue with out of
tree module authors that because they don't have network namespace
support in their modules, their modules are broken.
Does this imply that every module that
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to
care about
namespaces. My first impression is that my module should be able to
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] 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
Ben Greear [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to care
about
namespaces. My first impression
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to care about
Ben Greear [EMAIL PROTECTED] writes:
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
Ben Greear [EMAIL PROTECTED] writes:
Ok, but can a netdev at least know what namespace it is in? I don't
need this for my module, but it seems very useful knowledge...
Sure. dev-nd_net
It is a don't care not a don't know, and there should be device
events when it goes in and out of a
From: Ben Greear [EMAIL PROTECTED]
Date: Tue, 04 Dec 2007 10:57:01 -0800
echo add_my_bridge my_br1 eth0 namespaceX eth1 namespaceY
/proc/net/foo/config
Each process executes in a namespace, so specifying the namespace
is redundant, just fetch the current process's namespace to pass
into the
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 11:03:01 -0700
I am confused. I don't see a path forward that feels right.
Eric, instead of writing a book about how you feel, look
at the simple facts and resolve this quickly.
You added a new key, the namespace, to the
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Tue, 04 Dec 2007 12:17:57 -0700
Ben Greear [EMAIL PROTECTED] writes:
If I *do* need to add some sort of namespace
awareness to just achieve today's functionality, I don't mind making the
changes,
so long as I don't need to change to GPL
Patrick McHardy wrote:
Adrian Bunk wrote:
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
For all I care binary modules can break, but frankly I don't see
how encapsulating a couple of structures and pointers in a new
structure and adding a new argument to existing functions
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote:
Stephen Hemminger wrote:.
I spoke too soon earlier, ndiswrapper builds and loads against current
2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again
I don't
give a damn, but the enterprise distro vendors
On Mon, 03 Dec 2007 09:24:15 +0100
Romano Giannetti [EMAIL PROTECTED] wrote:
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote:
Stephen Hemminger wrote:.
I spoke too soon earlier, ndiswrapper builds and loads against
current 2.6.24-rc3. Vmware and proprietary VPN software
Patrick McHardy [EMAIL PROTECTED] writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
This code doesn't need or care about name-spaces, so I don't see how it
Romano Giannetti [EMAIL PROTECTED] writes:
Please pardon me for jumping in; I am not a kernel developer, but I try
to help with debugging whenever I can (and it's not just hand-waving, I
helped to track down a couple of nasty bugs on MMC or ACPI EC,
recently). And I am an engineer and IANAL,
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
This code doesn't need or care about
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Mon, 03 Dec 2007 11:03:38 -0700
Based on my experience with in-tree code and the few glimpses I
have gotten of out of tree code the reason the out of tree code broke
is because it is doing very questionable things.
Calling dev_get_by_foo() was
Ben Greear wrote:
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a
bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
This code doesn't need
On Sat, 1 Dec 2007 16:30:35 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
On Sat, 1 Dec 2007 11:17:36 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any issues here,
since they can just patch their kernels around any issues.
But it looks like Eric has this one thought out well enough.
So you are saying all this is not a problem, fine.
Any affected
On Sun, 02 Dec 2007 13:51:04 GMT, Alan Cox said:
On Sat, 1 Dec 2007 16:30:35 -0800
I spoke too soon earlier, ndiswrapper builds and loads against current
2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again
I don't
give a damn, but the enterprise distro vendors
Ben Greear wrote:
Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any
issues here,
since they can just patch their kernels around any issues.
But it looks like Eric has this one thought out well enough.
So you are saying all this is not a
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
Ben Greear wrote:
Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any issues
here,
since they can just patch their kernels around any issues.
But it looks like Eric has this one thought
Adrian Bunk wrote:
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
For all I care binary modules can break, but frankly I don't see
how encapsulating a couple of structures and pointers in a new
structure and adding a new argument to existing functions shifts
the decision
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
Why - they aren't exactly likely to be permissible by law
Really? What law and/or what clause in the GPL says that derivative works
have to be licensed
You license yours under the GPL, so they should respect the GPL.
It sounds like we're back to where we were years ago. Didn't we already
agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had
nothing to do with respecting the GPL? After all, if it s a GPL-enforcement
No
On Sun, Dec 02, 2007 at 10:59:46PM +0100, Patrick McHardy wrote:
Adrian Bunk wrote:
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
...
your statement has an interesting implication:
Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL
stuff.
Who is
Mark Lord wrote:
Now that we have network namespace support merged it is time to
revisit the sysfs support so we can remove the dependency on !SYSFS.
...
Now that the namespace updates are part of 2.6.24,
there is a major inconsistency in network EXPORT_SYMBOLs.
It used to be that an external
Now that we have network namespace support merged it is time to
revisit the sysfs support so we can remove the dependency on !SYSFS.
...
Now that the namespace updates are part of 2.6.24,
there is a major inconsistency in network EXPORT_SYMBOLs.
It used to be that an external network module
On Sat, 01 Dec 2007 08:10:17 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Now that we have network namespace support merged it is time to
revisit the sysfs support so we can remove the dependency on !SYSFS.
...
Now that the namespace updates are part of 2.6.24,
there is a major inconsistency
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
Why - they aren't exactly likely to be permissible by law
binary seething masses from accessing random kernel functions, and allowing
reasonable (but still
Stephen Hemminger [EMAIL PROTECTED] writes:
On Sat, 01 Dec 2007 08:10:17 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Now that we have network namespace support merged it is time to
revisit the sysfs support so we can remove the dependency on !SYSFS.
...
Now that the namespace updates are
On Sat, 1 Dec 2007 19:23:41 +
Alan Cox [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
Why - they aren't exactly likely to be permissible by law
Matter of debate in which
Then change the license, explicitly and get it approved, forcing license
changes by technically subversive means is bad policy. It is like Euro
bureaucrats
I don't need to - the licence has been the same since about 0.12
Alan
--
To unsubscribe from this list: send the line unsubscribe netdev
Stephen Hemminger [EMAIL PROTECTED] writes:
Actually, the whole mess would go away if the api for dev_get_by_ hadn't
been changed in the namespace transition. IMHO the interface to
dev_get_by_name()
should not have added a namespace parameter, of the callers in the tree, only
two use a
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Actually, the whole mess would go away if the api for dev_get_by_ hadn't
been changed in the namespace transition. IMHO the interface to
dev_get_by_name()
should not have added a namespace parameter, of the callers in the
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated dev_get_by_ that takes a network
namespace parameter.
..
And what should code be passing in when # CONFIG_NET_NS is
Mark Lord [EMAIL PROTECTED] writes:
Can we get this resolved before 2.6.24 is released? Going back and forth
on API's is just needless frottage.
Sure. We keep the updated dev_get_by_ that takes a network
namespace parameter.
..
And what should code be passing in when # CONFIG_NET_NS
Arjan van de Ven wrote:
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated dev_get_by_ that takes a network
namespace parameter.
..
And what should code be passing in when
Arjan van de Ven wrote:
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated dev_get_by_ that takes a network
namespace parameter.
..
And what should code be passing in when
On 12/02/2007 12:13 AM, Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Fine. But all of them want to call sk_alloc(),
network drivers should be calling sk_alloc less then they should
call dev_get_by_. Only protocols call sk_alloc.
and many want to do register_netdev().
Mark Lord [EMAIL PROTECTED] writes:
Arjan van de Ven wrote:
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated dev_get_by_ that takes a network
namespace parameter.
..
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Arjan van de Ven wrote:
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated dev_get_by_ that takes a network
On Sat, 1 Dec 2007 11:17:36 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
binary seething masses from accessing random kernel functions, and allowing
Mark Lord [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Arjan van de Ven wrote:
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Eric W. Biederman wrote:
Stephen Hemminger [EMAIL PROTECTED] writes:
Sure. We keep the updated
Jiri Slaby [EMAIL PROTECTED] writes:
On 12/02/2007 12:13 AM, Eric W. Biederman wrote:
Mark Lord [EMAIL PROTECTED] writes:
Fine. But all of them want to call sk_alloc(),
network drivers should be calling sk_alloc less then they should
call dev_get_by_. Only protocols call sk_alloc.
Stephen Hemminger [EMAIL PROTECTED] writes:
On Sat, 1 Dec 2007 11:17:36 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
binary seething masses from
Stephen Hemminger wrote:
On Sat, 1 Dec 2007 11:17:36 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line between keeping the
binary seething masses from accessing random kernel
On Sat, 01 Dec 2007 22:34:09 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Sat, 1 Dec 2007 11:17:36 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
Then init_net needs to be not GPL limited. Sorry, we need to allow
non GPL network drivers. There is a fine line
51 matches
Mail list logo
