On Fri, Sep 24, 2010 at 07:51:24AM -0400, jamal wrote:
> > migrating route table entries makes no sense because
> > a) they refer to devices and configuration that does not exist in the
> >target namespace; they only make sense within their netns context
> > b) they are purely virtual and you g
On Fri, Sep 24, 2010 at 09:32:53AM -0400, jamal wrote:
> On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> > No. While you sure could associate routes with devices, they don't
> > *functionally* reside on top of network devices. They reside on top of
> > the entire IP configuration,
>
>
On Thu, Sep 23, 2010 at 07:22:06AM -0400, jamal wrote:
> On Thu, 2010-09-23 at 01:51 -0700, Eric W. Biederman wrote:
> > Take advantage of the new abstraction and allow network devices
> > to be placed in any network namespace that we have a fd to talk
> > about.
>
> So ... why just netdevice? cou
On Fri, 2010-09-24 at 16:09 +0200, David Lamparter wrote:
> I understood your point. What I'm saying is that that functional graph
> you're describing is too simplistic do be a workable model. Your graph
> allows for what you're trying to do, yes. But your graph is not modeling
> the reality.
How
On 09/23/2010 10:51 AM, Eric W. Biederman wrote:
>
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
> Signed-off-by: Eric W. Biederman
> ---
[ ... ]
> +struct net *get_net_ns_by_fd(int fd)
> +{
> + s
On Fri, 2010-09-24 at 14:57 +0200, David Lamparter wrote:
> No. While you sure could associate routes with devices, they don't
> *functionally* reside on top of network devices. They reside on top of
> the entire IP configuration,
I think i am not clearly making my point. There are data dependen
On Thu, 2010-09-23 at 16:58 +0200, David Lamparter wrote:
> migrating route table entries makes no sense because
> a) they refer to devices and configuration that does not exist in the
>target namespace; they only make sense within their netns context
> b) they are purely virtual and you get t
Brian Haley writes:
> On 09/23/2010 04:51 AM, Eric W. Biederman wrote:
>>
>> Take advantage of the new abstraction and allow network devices
>> to be placed in any network namespace that we have a fd to talk
>> about.
>>
> ...
>> +struct net *get_net_ns_by_fd(int fd)
>> +{
>> +struct proc_i
Eric Dumazet writes:
> Le jeudi 23 septembre 2010 à 01:51 -0700, Eric W. Biederman a écrit :
>> Take advantage of the new abstraction and allow network devices
>> to be placed in any network namespace that we have a fd to talk
>> about.
>>
>> Signed-off-by: Eric W. Biederman
>> ---
>> include/
jamal writes:
> On Thu, 2010-09-23 at 01:51 -0700, Eric W. Biederman wrote:
>> Take advantage of the new abstraction and allow network devices
>> to be placed in any network namespace that we have a fd to talk
>> about.
>>
>
> So ... why just netdevice? could you allow migration of other
> net "
On 09/23/2010 04:51 AM, Eric W. Biederman wrote:
>
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
...
> +struct net *get_net_ns_by_fd(int fd)
> +{
> + struct proc_inode *ei;
> + struct file *fi
On Thu, 2010-09-23 at 01:51 -0700, Eric W. Biederman wrote:
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
So ... why just netdevice? could you allow migration of other
net "items" eg a route table sin
Le jeudi 23 septembre 2010 à 01:51 -0700, Eric W. Biederman a écrit :
> Take advantage of the new abstraction and allow network devices
> to be placed in any network namespace that we have a fd to talk
> about.
>
> Signed-off-by: Eric W. Biederman
> ---
> include/linux/if_link.h |1 +
>
13 matches
Mail list logo
