History log of /linux-master/tools/net/ynl/generated/Makefile
Revision Date Author Comments
# 4e887471 04-Mar-2024 Jakub Kicinski <kuba@kernel.org>

tools: ynl: rename make hardclean -> distclean

The make target to remove all generated files used to be called
"hardclean" because it deleted files which were tracked by git.
We no longer track generated user space files, so use the more
common "distclean" name.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>


# d2866539 01-Feb-2024 Jakub Kicinski <kuba@kernel.org>

tools: ynl: auto-gen for all genetlink families

Instead of listing the genetlink families that we want to codegen
for, always codegen for everyone. We can add an opt-out later but
it seems like most families are not causing any issues, and yet
folks forget to add them to the Makefile.

Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20240202004926.447803-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# 7c59c9c8 01-Feb-2024 Jakub Kicinski <kuba@kernel.org>

tools: ynl: generate code for ovs families

Add ovs_flow, ovs_vport and ovs_datapath to the families supported
in C. ovs-flow has some circular nesting which is fun to deal with,
but the necessary support has been added already in the previous
release cycle.

Add a sample that proves that dealing with fixed headers does
actually work correctly.

Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20240202004926.447803-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# 8f109e91 01-Feb-2024 Jakub Kicinski <kuba@kernel.org>

tools: ynl: include dpll and mptcp_pm in C codegen

The DPLL and mptcp_pm families are pretty clean, and YNL C codegen
supports them fully with no changes. Add them to user space codegen
so that C samples can be written, and we know immediately if changes
to these families require YNL codegen work.

Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20240202004926.447803-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# f14122b2 05-Oct-2023 Chuck Lever <chuck.lever@oracle.com>

tools: ynl: Add source files for nfsd netlink protocol

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>


# cb7fb0aa 10-Oct-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: use ynl-gen -o instead of stdout in Makefile

Jiri added more careful handling of output of the code generator
to avoid wiping out existing files in
commit f65f305ae008 ("tools: ynl-gen: use temporary file for rendering")
Make use of the -o option in the Makefiles, it is already used
by ynl-regen.sh.

Link: https://lore.kernel.org/r/20231010202714.4045168-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# a5066017 03-Oct-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: don't regen on every make

As far as I can tell the normal Makefile dependency tracking
works, generated files get re-generated if the YAML was updated.
Let make do its job, don't force the re-generation.
make hardclean can be used to force regeneration.

Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/r/20231003153416.2479808-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# f0ec58d5 13-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: work around stale system headers

The inability to include the uAPI headers directly in tools/
is one of the bigger annoyances of compiling user space code.
Most projects trade the pain for smaller inconvenience of having
to copy the headers under tools/include.

In case of netlink headers I think that we can avoid both.
Netlink family headers are simple and should be self-contained.
We can try to twiddle the Makefile a little to force-include
just the family header, and use system headers for the rest.

This works fairly well. There are two warts - for some reason
if we specify -include $path/family.h as a compilation flag,
the #ifdef header guard does not seem to work. So we need
to throw the guard in on the command line as well. Seems like
GCC detects that the header is different and tries to include
both. Second problem is that make wants hash sign to be escaped
or not depending on the version. Sigh.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


# 2d7be507 09-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: generate code for the ethtool family

Generate the protocol code for ethtool. Skip the stats
for now, they are the only outlier in terms of complexity.
Stats are a sort-of semi-polymorphic (attr space of a nest
depends on value of another attr) or a type-value-scalar,
depending on how one wants to look at it...
A challenge for another time.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


# 5d1a30eb 07-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: generate code for the devlink family

Admittedly the devlink.yaml spec is fairly limitted,
it only covers basic device get and info-get ops.
That's sufficient to be useful (monitoring FW versions
in the fleet). Plus it gives us a chance to exercise
deep nesting and directional messaging in YNL.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# 7a11f70c 06-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: generate code for the handshake family

Generate support for the handshake family.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# d75fdfbc 05-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: support fou and netdev in C

Generate the code for netdev and fou families. They are simple
and already supported by the code gen.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# 86878f14 05-Jun-2023 Jakub Kicinski <kuba@kernel.org>

tools: ynl: user space helpers

Add "fixed" part of the user space Netlink Spec-based library.
This will get linked with the protocol implementations to form
a full API.

Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>