/scripts/lib
/tools/lib
/python/lib
eventually with their own sub-directories on it, like what we have
today:
${some_prefix}/kdoc
${some_prefix}/abi
In the case of netlink, it could be:
${some_prefix}/netlink
Yet, IMO, we should not have a different location for userspace
and non-userspace, as it is very hard to draw the borders on several
cases, like the ABI toolset.
> > Eventually, some classes might be re-used in the future
> > by multiple scripts and subsystems, when it makes sense, just like we do
> > already with Kernel's kAPIs. This also helps when checking what is the
> > Python's minimal version that are required by the Kernel when updating
> > it at:
>
> I think this is exactly the same point Donald is making, but from YNL
> perspective. The hope is to share more code between the ReST generator,
> the existing C generator and Python library. The later two are already
> based on a shared spec model.
That makes perfect sense to me. Yet, this doesn't preventing having
a:
${some_prefix}/ynl
directory where you would place Netlink YNL parsing, where the prefix
would be either:
- /scripts/lib
- /tools/lib
- /python/lib
- something else
It may even use some common classes under:
${some_prefix}/${some_common_prefix}
---
Now, seeing your comments, maybe the main point is wheather it is OK to
add userspace libraries to scripts/lib or not. IMO, using "/scripts/lib"
is OK, no matter if the script is kernel-build related or "pure userspace",
but if there are no consensus, we could migrate what we have to
"python/lib" or to some other place.
Thanks,
Mauro
