netdev - Re: [RFC PATCH net-next 0/2] Add new switchdev device class

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, 27 Aug 2015 09:27:22 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	sfeldma@...il.com
Cc:	netdev@...r.kernel.org, davem@...emloft.net, f.fainelli@...il.com,
	roopa@...ulusnetworks.com
Subject: Re: [RFC PATCH net-next 0/2] Add new switchdev device class

Thu, Aug 27, 2015 at 09:16:44AM CEST, sfeldma@...il.com wrote:
>From: Scott Feldman <sfeldma@...il.com>
>
>In the switchdev model, we use netdevs to represent switchdev ports, but we
>have no representation for the switch itself.  So, introduce a new switchdev
>device class so we can define semantics and programming interfaces for the
>switch itself.  Switchdev device class isn't tied to any particular bus.
>
>This patch set is just the skeleton to get us started.  It adds the sysfs
>object registration for the new class and defines a class-level attr "foo".
>With the new class, we could hook PM functions, for example, to handle power
>transitions at the switch level.  I registered rocker and get:
>
>   $ ls /sys/class/switchdev/5254001235010000/
>   foo  power  subsystem  uevent

No, please avoid adding anything to sysfs. If we need to add anything,
lets make is accesible using Netlink only.


>
>So what next?  I'd rather not build APIs around sysfs, so we need a netlink API
>we can build on top of this.  It's not really rtnl.  Maybe genl would work?
>What ever it is, we'd need to teach iproute2 about a new 'switch' command.
>
>Netlink API would allow us to represent switch-wide objects such as registers,
>tables, stats, firmware, and maybe even control.  I think with with netlink
>TLVs, we can create a framework for these objects but still allow the switch
>driver provide switch-specific info.  For example, a table object:
>
>[TABLES]
>	[TABLE]
>		[FIELDS]
>			[FIELD]
>				[ID, TYPE]
>		[DATA]
>			[ID, VALUE]

Alert! I feel that someone would like to abuse this iface for writing
configuration through. This should be read-only by design. I also think
that this should not be something switch-specific. I believe that NIC
drivers would benefit from this iface as well when they want to expose
something. I think we should use genl for this.


>
>Maybe iproute2 has pretty-printers for specific switches like ethtool has for
>reg dumps.

I feel like a lot of what you described overlaps with existing
interfaces and tools. Why don't we just reuse that? For firmware for
example, just take one of the ports. Same for stats (I plan to expose my
mlxsw switch-wide stats in ethtool so they are accessible through every
port netdevice).

I still do not see the need for new device class. I have strong feeling
that it should be avoided.

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