# Why so many sysctl() wrapper libraries?



## Samuel Venable (Jul 31, 2020)

There are a good number of sysctl wrapper libraries and api's for FreeBSD and other BSD distro's. Darwin has libproc.h and proc_info.h. FreeBSD libutil, libprocstat, and several others. What I don't get is, if you are going to make several libraries wrapping a single complicated api function, to try to make it simpler to work with, shouldn't there be less overlap in what each individual library does? libutil and libprocstat for example have all the same exact features, except libprocstat can do a few extra things like get the cmdline, cwd, and environ of a given process. Why do we need both of these libraries built in to the operating system? Wouldn't it be better to combine them in a new library and deprecate the current ones? Or would that break too many projects too quickly for developers to want to keep up with?

Also, my process information library I am writing has a FreeBSD and Darwin/MacOS port, I think it would be relatively easy to port the base Darwin libraries my library uses to FreeBSD or vise versa, simply by recompiling them from existing source code with very little modification where needed. All of that is great if there are no licensing issues. But it would be cool to have a single sysctl wrapper that came shipped with most BSD distro's out of the box? OpenBSD for example doesn't have FreeBSD's libutil header and library. I get the different projects have different developers who make different decisions on project direction. But I feel if there was a single library for simplifying sysctl that was good enough and covered enough relevent functionality there everyone would resort to that one library on every BSD system while writing software for the BSD's instead of referencing different ones for each distro.

I can understand there being variations in api's like this for completely different operating systems but not different distro's of the same operating system at its core. Do you guys find this completely necessary?

My library's goal is to help fix this problem to some extent, but there will be a lot of maintenance needed higher level because of the api changes at the lower level. The less differences at the lower level the better, that's my personal thought on if you are going to have separate distro's. Different operating systems is a bit different because they come from different codebases completely.

I dont really mind the maintenance. I just don't see why so many people need to make compatibility breaking decisions.

I wanted to at some point to do a lower level version of my library for BSD that is based on sysctl directly as that will make it easier. Another thing I was interested in knowing, who would i contact if i wanted to develop this library as an official FreeBSD library? I wanted to contact the main FreeBSD developers and other major distro's like OpenBSD to get a more universal library going that will be included with most of the major BSD's to sort of replace all the duplicated functionality done differently. I don't mean the third party ports. If I could work with the official devs and get their insight, I would like to make this library as efficient and good as it can get for process related functionality.

Edit:

Sorry for editing my post so much. I feel kinda nervous about posting due to my last thread's reaction.


----------



## ralphbsz (Jul 31, 2020)

Samuel Venable said:


> Why do we need both of these libraries built in to the operating system? Wouldn't it be better to combine them in a new library and deprecate the current ones?


A: Deprecating something that works and needs very little maintenance is a bad idea. Lots of people out there are relying on these libraries, and you'll force all of them to adapt their code. Now, if these libraries required constant maintenance, that would be different, but I don't think they do.
B: You are assuming that there is a single benevolent dictator (or obnoxious dictator) who can make decisions about what to deprecate, and how to move work around between people (between OS implementors and OS users, and between implementors/maintainers for different subsystems). I'm not sure such a dictator exists in FreeBSD. I know that such tradeoffs are made in commercial software, but that's not where we are.



> But I feel if there was a single library for simplifying sysctl that was good enough and covered enough relevent functionality there everyone would resort to that one library on every BSD system while writing software for the BSD's instead of referencing different ones for each distro.


If such a library had existed at the time the various softwares were written, that would have been true. But it wasn't, and most software is not continuously overhauled.



> ... but not different distro's of the same operating system at its core.


The BSDs are not distros of the same operating system. They are separate projects, with very little overlap in people, and de-facto none in decision making. What they share is a common code base, but the divergence in the last 15-25 years has been significant. And since most of the people doing development and maintenance on the *BSDs are volunteers, to some extent they will do what they want (the exception being Darwin, but that is from a source code standpoint mostly not BSD).


> I wanted to contact the main FreeBSD developers and other major distro's like OpenBSD to get a more universal library going that will be included with most of the major BSD's to sort of replace all the duplicated functionality done differently. I don't mean the third party ports. If I could work with the official devs and get their insight, I would like to make this library as efficient and good as it can get for process related functionality.


That is a question for the developer mailing lists. To get the attention of the core developers, you probably would have to have a working prototype for all OSes ready to go. I think it is a great idea to volunteer for this, but don't underestimate the commitment.


----------



## Samuel Venable (Jul 31, 2020)

I'll ask the developer mailing list, I had a feeling that was the place to ask, thanks you!

I think deprecating stuff too quickly is always bad and Apple often does that for seemingly no reason, sometimes as simple as renaming a constant, so I get why the open source community strives to take a different route and annoy less people by keeping backwards compatibility, and that makes more sense to me now that you mention it. Microsoft is pretty big on that as well despite being closed source.


----------



## mark_j (Jul 31, 2020)

Samuel Venable said:


> There are a good number of sysctl wrapper libraries and api's for FreeBSD and other BSD distro's. Darwin has libproc.h and proc_info.h. FreeBSD
> 
> [...snip...]



It's really simple. FreeBSD != OpenBSD != NetBSD != ...

While they share a common ancestry, they're not that close now. If anything, FreeBSD and NetBSD have maintained more common ground than OpenBSD. They are not distibutions of some singular BSD. They might have been back in the early '90s but not now. They are not like Linux. They do not have a common kernel.

To prove it, use the common C compiler macro __BSD__ in code for FreeBSD specific stuff and it will break in NetBSD.


----------



## Samuel Venable (Jul 31, 2020)

Oh wow, there are a lot of technical/development-related mailing lists. I mean hot dog!









						Appendix C. Resources on the Internet
					

FreeBSD additional resources on internet like websites, mailing lists, mirrors, etc




					www.freebsd.org
				




Well, I guess I'll go with the freebsd-hackers one for general development as there seems to be nothing specifically geared towards process information.


----------



## mark_j (Jul 31, 2020)

freebsd-arch


----------



## Samuel Venable (Jul 31, 2020)

I dunno how I missed that being at the very top. Thank you and sorry about the other topic. Hopefully everyone who saw it or replied there can forget about it.


----------

