[woodman]

I switched from CentOS to FreeBSD as my daily driver a little over a year ago, for the ports tree. I needed a bleeding edge version of valgrind, but my ~/bin and ~/lib were already pretty unwieldy - so that is what caused the switch. That and ZFS. But I've found a couple of other things that I really like: the documentation is awesome, and config files are where you'd expect them to be. Being able to tune system internals online with sysctl is really awesome as well. Wanna change the lowest possible C-state one cpu3? sysctl hw.acpi.cpu.3.cx_lowest=C3.

I dunno how useful that is for web devs, but as a C programmer and perpetual tinkerer - FreeBSD suits my needs very nicely.

[icebraining]

Linux has sysctl as well, and other parameters can be set by writing to the right files in /sys. For example, the maximum c-state can be set by writing to /sys/module/processor/parameters/max_cstate (if you have support enabled in the kernel).

[woodman]

The linux sysctl is a wrapper for kernel state represented in the file system, freebsd sysctl is direct to kernel. So that is nice, everything in one place. Before my switch to freebsd, I had been a linux user since 2000 - and while I was aware of the existence of sysctl, I don't remember seeing it used very often. It was much more common to see direct interaction with stuff in /proc (rockectraid, never again). Why is that? Is it an issue with standardizing driver interaction or what?

My prior post wasn't written as a statement of exclusivity, simply that I prefer the way freebsd does it.

[caf]

The /proc/sys/ and sysctl(2) methods are really just down to which syscall is used to talk to the kernel - either way it's just reading or writing a kernel-side data structure, there's no fundamental difference there.

The /proc/sys/ pseudo-filesystem interface has the advantage that it's discoverable. The sysctl(2) interface requires userspace to have knowledge of a swag of hardcoded ID numbers identifying each node in the sysctl tree.

[woodman]

I haven't poked through the code, but the linux man page isn't encouraging: "use the /proc/sys interface instead" [0]

Compare that to the freebsd man page [1]

[0] http://man7.org/linux/man-pages/man2/sysctl.2.html#NOTES

[1] https://www.freebsd.org/cgi/man.cgi?query=sysctl&sektion=3&m...

[caf]

I think perhaps we might be talking at cross-purposes here.

My point is that when you call write(2) under Linux on a file descriptor derived from opening a /proc/sys pseudo-file you are talking directly to the kernel code responsible for updating the sysctl variables in the same way as you are when you call sysctl(2) under FreeBSD.

The /proc/sys files aren't real files - they're just a way of representing the sysctl variables in the existing file namespace.

[woodman]

Ah, when you said sysctl(2) I thought you were talking about the linux call - which is basically dead code. Yeah I don't really have a beef with the whole "everything is a file" design, I actually quite like it, but I really like how well freebsd has done sysctl - both the subroutine (3) and the command (8).