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: <84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au>
Date: Fri, 08 Nov 2024 16:10:49 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Jakub Kicinski <kuba@...nel.org>, Khang Nguyen
	 <khangng@...amperecomputing.com>
Cc: Matt Johnston <matt@...econstruct.com.au>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
 Horman <horms@...nel.org>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, 
 ampere-linux-kernel@...ts.amperecomputing.com, Phong Vo
 <phong@...amperecomputing.com>, Thang Nguyen
 <thang@...amperecomputing.com>,  Khanh Pham <khpham@...erecomputing.com>,
 Phong Vo <pvo@...erecomputing.com>, Quan Nguyen
 <quan@...amperecomputing.com>, Chanh Nguyen <chanh@...amperecomputing.com>,
  Thu Nguyen <thu@...amperecomputing.com>, Hieu Le
 <hieul@...erecomputing.com>, openbmc@...ts.ozlabs.org, 
 patches@...erecomputing.com
Subject: Re: [PATCH net-next] net: mctp: Expose transport binding identifier
 via IFLA attribute

Hi Jakub,

> > However, we currently have no means to get this information from
> > MCTP links.
> 
> I'm not opposed to the netlink attribute, but to be clear this info 
> is indirectly available in sysfs, right? We link the netdev to 
> the parent device so the type of /sys/class/net/$your_ifc/device
> should reveal what the transport is?

It's likely derivable from the parent device, but requires some
heuristics in userspace to map this to a transport type.

Having a well-defined place to provide the DMTF-specified transport
identifier makes this a little more straightforward to determine which
spec we're dealing with, for any transport-specific behaviour. For
example, some bus types require endpoints to announce their presence,
others do not.

Cheers,


Jeremy


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ