> -----Original Message----- > From: Jakub Kicinski <kuba@xxxxxxxxxx> > Sent: Monday, July 25, 2022 6:14 PM > To: Keller, Jacob E <jacob.e.keller@xxxxxxxxx> > Cc: Jiri Pirko <jiri@xxxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx > Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update > > Hm, yes. Don't invest too much effort into rendering per-cmd policies > right now, tho. I've started working on putting the parsing policies > in YAML last Friday. This way we can auto-gen the policy for the kernel > and user space can auto-gen the parser/nl TLV writer. Long story short > we can kill two birds with one stone if you hold off until I have the > format ironed out. For now maybe just fork the policies into two - > with and without dry run attr. We'll improve the granularity later > when doing the YAML conversion. I'm also worried about the process for transitioning from the existing non-strict policy to a strict validation of per-command policies. How does that impact backwards compatibilty, and will we need to introduce new ops or not? I know we had to introduce new ops for the strict versions of the PTP ioctls. However those were dealing with (possibly) uninitialized values, where-in userspace may have been accidentally sending values so we could no longer extend the reserved fields. For netlink, in this case the userspace code would need to be intentionally adding netlink attributes. I would think that well behaved userspace would rather get an error when the command isn't honoring an attribute... But in a technical sense that would still be breaking backwards compatibility, since it would cause an application that used to "work" to break. Ofcourse in the case of something like DEVLINK_ATTR_DRY_RUN, the userspace may not be working as intended, and it might be considered a bug. In short: for backwards compatibility, it seems like we might not be able to migrate existing ops to strict validation and would need to replace them? That seems like a very big step...
