netdev - RE: [patch net-next RFC 3/3] net: export physical port id via sysfs

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]

Date:	Thu, 18 Jul 2013 01:09:41 +0530
From:	<Narendra_K@...l.com>
To:	<jiri@...nulli.us>
CC:	<netdev@...r.kernel.org>, <bhutchings@...arflare.com>,
	<john.r.fastabend@...el.com>
Subject: RE: [patch net-next RFC 3/3] net: export physical port id via sysfs

> -----Original Message-----
> From: Jiri Pirko [mailto:jiri@...nulli.us]
> Sent: Wednesday, July 17, 2013 2:00 PM
> To: K, Narendra
> Cc: netdev@...r.kernel.org; bhutchings@...arflare.com;
> john.r.fastabend@...el.com
> Subject: Re: [patch net-next RFC 3/3] net: export physical port id via sysfs
> 
> Tue, Jul 16, 2013 at 10:03:04PM CEST, Narendra_K@...l.com wrote:
[...] 
> >> +static ssize_t show_phys_port_id(struct device *dev,
> >> +				 struct device_attribute *attr, char *buf) {
> >> +	struct net_device *netdev = to_net_dev(dev);
> >> +	ssize_t ret = 0;
> >> +
> >> +	if (!rtnl_trylock())
> >> +		return restart_syscall();
> >> +
> >> +	if (dev_isalive(netdev) && netdev->netdev_ops-
> >> >ndo_get_phys_port_id) {
> >> +		struct netdev_phys_port_id ppid;
> >> +
> >> +		ret = netdev->netdev_ops->ndo_get_phys_port_id(netdev,
> >> &ppid);
> >[>]
> >
> >Hello,
> >I am thinking if "ndo_get_phys_port_id()" is required.  With it, the driver
> needs to generate port_id  every time "ndo_get_phys_port_id()" is called,
> but the "netdev->phys_port.port_id" might not have changed.  If 'phys_port'
> structure is part of 'struct net_device',  then 'netdev->phys_port.port_id'
> and port_id_len are set by driver before calling 'register_netdev' and are
> available to the core.  Driver not implementing it would indicate it by a
> "port_id_len" of zero.     If the "netdev->phys_port.port_id" changes for
> some reason then the notification sent by the driver would ensure that the
> interested kernel components and user space are notified of the change.
> 
> Although this can be done by extending netdevice structure by another item,
> I believe it is cleaner to do it by ndo. Driver has a flexibility to either compute
> the phys port on fly of compute it once, store it in it's private data and use it
> when ndo is called.

It seems to me that phys_port identifier is a net_device property,  similar to netdev->dev_addr or netdev->if_port, and could be part of struct net_device  as discussed in [1].  My understanding may not be correct.

Hello Ben,  for the hybrid guest networking scenario, would it be required/helpful for phys_port to be part of net_device structure or either of the approaches would be fine.

With regards,
Narendra K
Linux Engineering
Dell Inc.

[1] http://marc.info/?l=linux-netdev&m=136920998009209&w=2

--
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