Linux 5.5 Finally Doing Away With The SYSCTL System Call

[pal666]

When Linux gets rid of ioctl and sockets I'm willing to entertain the "kernel data as a filesystem is the only true way" argument.

pretty stupid requirement, considering filesystem supports both ioctl and (unix)sockets

[drjohnnyfever]

pretty stupid requirement, considering filesystem supports both ioctl and (unix)sockets

I really don't understand what you are saying. If ioctl and sockets were equivalent to special files Plan 9 wouldn't have replaced them with special files a la procfs in the name of more closely following the UNIX philosophy.

[drjohnnyfever]

pretty stupid requirement, considering filesystem supports both ioctl and (unix)sockets

You are aware that socket(2) and ioctl(2) are actual system calls and not /proc /sys special file interfaces right?

[coder]

I really don't understand what you are saying.

Most people just ignore him. Occasionally, he has a good point but mostly he trolls with posts that are almost too short.

I'll probably regret saying this, but I rather prefer his flavor of one-liners to longer troll-posts by certain other forum members. I guess because they're such obvious trolls that it's much easier to write him off and move on.

[Jabberwocky]

I'm not asserting FreeBSD's approach is superior, I'm am however more used to it. I think the UNIX Philosophy argument in favor of procfs is pretty weak. Yes everything as a file makes a lot of sense but it can be taken too far. Procfs in FreeBSD and Linux as far as I'm aware were modeled after the Plan9 implementation and didn't come from UNIX per-se anyway. When Linux gets rid of ioctl and sockets I'm willing to entertain the "kernel data as a filesystem is the only true way" argument.

Thanks for giving me some food for thought. It's challenging to comprehend everything relative to a desktop user or homelab server use case, never mind very specific like modern containers or tiny embedded. Currently I'm leaning towards FreeBSD's method for /proc on systems that are used by trained/professional humans. Linux's method could be easier for inexperienced people or basic autonomous systems.

Yes FreeBSD still has optional procfs support, mostly for quick and dirty ports of software with Linux-isms and to support the Linux-compat procfs for running Linux binaries. Inside it's implemented with sysctl(2). "Native" tools like top, htop, ps etc all use sysctl directly. The main reason for deprecating it was that it was a lot of code that wasn't being used actively since sysctl has been more popular on FreeBSD for ages.

This makes sense.

I have strong arguments for /dev and /sys but yes /proc has a more limited need. I've found /proc useful in some cases, although it's not very common. A simple case where a system does not have ps/top installed (as a contractor I see some odd systems). More advanced cases like getting open file descriptors feels easier/more-intuitive to use "/proc/<pid>/fd" than having to learn procstat or fdescfs. It's probably also easier to interface a program with /proc as there's more code re-usability between use cases. That's just my opinion at this point in time. I'm looking at it from a user's perspective and have no idea about code simplicity and maintainability over user functionality in kernel or "OS-provided-userland" applications.

It's sad when people can't take things into perspective and are reluctant to change opinion. Everything has pros and cons. Windows has good remote desktop, active directory and commercial support. FreeBSD (and other flavors) allows extreme productivity and compatibility thanks to simple design. Linux pushes boundaries with bleeding edge technology and concepts in terms of hardware and software. I know it's useful to "go with what you know", but the amount of professionals that I meet during contracting that are set in their ways is just crazy. I wish I was allowed to blog/vlog about this in detail...

I used FreeBSD daily for ~5 years. I really enjoyed the simplicity and productiveness when the conditions where right. Many of the conditions were related to popularity and not design for example hardware or application support which is unfortunate (same is true for Linux, just more common today). Thanks to simple design OS upgrades were very easy. Enterprise Linux distros come close sometimes, but majority like popular Ubuntu utterly fail in this regard.

On to bigger problems... country's power is out again and I need to do make my rounds.

[coder]

I have strong arguments for /dev and /sys but yes /proc has a more limited need. I've found /proc useful in some cases, although it's not very common. A simple case where a system does not have ps/top installed (as a contractor I see some odd systems). More advanced cases like getting open file descriptors feels easier/more-intuitive to use "/proc/<pid>/fd" than having to learn procstat or fdescfs. It's probably also easier to interface a program with /proc as there's more code re-usability between use cases. That's just my opinion at this point in time. I'm looking at it from a user's perspective and have no idea about code simplicity and maintainability over user functionality in kernel or "OS-provided-userland" applications.

Besides looking at fds, I frequently run:

strings /proc/###/cmdline

When I first started using Linux, I just loved the feeling of being able to inspect the system state, simply by using the filesystem. It just felt so "open", and like the systems guts were all there for you to inspect and poke around at. Windows gave me a very different vibe, where you had to use APIs and specialized tools like regedit.