lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51B219D9.2010900@gmail.com>
Date:	Fri, 07 Jun 2013 10:35:21 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	Narendra K <narendra_k@...l.com>, stephen@...workplumber.org,
	netdev@...r.kernel.org
Subject: Re: Generic interface to make physical port number used by a netdevice
 available to user space

[...]

> Having looked at the qeth driver now, I think the comment in netdevice.h
> should be changed to state that this is for distinguishing devices that
> share a link-layer address, and the drivers using it for other purposes
> should stop doing so (if that doesn't break userland).
>

Agreed, the qeth driver eluded me, its not in ./drivers/net as you
noted in the other thread.

> [...]
>>> 3. Add a new field 'physport' to 'struct net_device' and export it to sysfs.
>>
>> Probably not we already have two fields that seem ill-defined no reason
>> to add another to the confusion. If you absolutely can't make dev_id or
>> if_port coherent then maybe but I really think one of the above two will
>> work.
>
> I think we should tighten up documentation and implementation of the
> existing fields, but there is still a need for this new one.
>
> One thing that needs to be clearly specified is the scope of the
> physport identifier - the controller, board, physical machine, ... or
> universe.  In a VM, controller and board scope are pretty useless as it
> typically can't tell which devices belong to the same controller or
> board anyway.  A universally unique identifier is probably not too hard
> to implement as there is likely to be at least one MAC address
> permanently assigned to each physical port.
>
> Ben.
>

OK, sounds reasonable to me a new field should work.


-- 
John Fastabend         Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ