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 ch
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
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 looki
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 ne
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:
>
>
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
namespace
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
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 sup
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 brid
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 modu
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 fut
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...
T
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
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 name
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() w
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 IA
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 s
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
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 exist
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 v
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
> 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
> > 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
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 about
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
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 problem,
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 ven
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 p
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 kee
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. Ther
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 funct
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 f
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 ca
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]
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
> r
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 netwo
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
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
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 wh
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 wh
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
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 "# CON
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 th
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 u
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 name
> 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 lin
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 wh
> 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
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 inco
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 n
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 cou
51 matches
Mail list logo
