> Nope. The initial functionality of libdladm was minimal. We had quite a > bit of input as to how the various subcommands of dladm should be named > and I tended to follow that guidance in naming the functions in libdladm > i.e. there was basically a one-to-one mapping between dladm subcommands > and libdladm functions.
And FWIW this is something we've continued to strive for with the libdladm API -- as is the core principle that all of the mechanism should be in the library and the dladm command should be by-and-large a wrapper that gathers the user's arguments and outputs error messages when appropriate. That said, these principles have not always been adhered to and as a result dladm is way more bloated than it should be. Sowmini has been making incremental progress on fixing this. More generally, I drafted a networking library API best practices write-up that I circulated a while back internally but I'm not sure it made it out. If there's interest, I'd be happy to send it out. It is not all-encompassing nor is it intended to be a mandate, but it contains a lot of the lessons learned from recent library APIs that we've done (e.g., libdlpi, libdladm, libipmp). -- meem
