Announcement

Collapse
No announcement yet.

Linux 5.5 Finally Doing Away With The SYSCTL System Call

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by Jabberwocky View Post
    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:

    Code:
    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.

    Leave a comment:


  • Jabberwocky
    replied
    Originally posted by drjohnnyfever View Post

    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.

    Leave a comment:


  • coder
    replied
    Originally posted by drjohnnyfever View Post
    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.

    Leave a comment:


  • drjohnnyfever
    replied
    Originally posted by pal666 View Post
    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?

    Leave a comment:


  • drjohnnyfever
    replied
    Originally posted by pal666 View Post
    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.

    Leave a comment:


  • pal666
    replied
    Originally posted by drjohnnyfever View Post
    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

    Leave a comment:


  • drjohnnyfever
    replied
    Originally posted by Jabberwocky View Post
    Looking at Linux sysctl.c I notice: Added /proc support, Dec 1995 That's a while ago.

    I guess FreeBSD does not agree with "Mike Gancarz: The UNIX Philosophy" ?

    Using procfs for userland interaction makes much more sense to me. For example (programmatically) explore, monitor, and change specific values dynamically like custom fan control. There's also the sysctl and config if you need bulk/one time changes. I wonder what FreeBSD's reason was to disable procfs (last time I checked it was disabled and not removed).
    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.

    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.

    Leave a comment:


  • jabl
    replied
    Originally posted by some_canuck View Post
    what about /etc/sysctl.conf? i definitely use that.
    That file is used by the aforementioned sysctl(8) tool, which uses the procfs interface. So it'll continue working as before.

    Leave a comment:


  • some_canuck
    replied
    what about /etc/sysctl.conf? i definitely use that.

    Leave a comment:


  • Jabberwocky
    replied
    Looking at Linux sysctl.c I notice: Added /proc support, Dec 1995 That's a while ago.

    Originally posted by drjohnnyfever View Post
    I find it interesting that Linux and FreeBSD went in opposite directions on this. FreeBSD deprecated the procfs interface (which as far as I know is implemented with sysctl(2) on FreeBSD) and Linux deprecated sysctl in favor of procfs.
    I guess FreeBSD does not agree with "Mike Gancarz: The UNIX Philosophy" ?

    Using procfs for userland interaction makes much more sense to me. For example (programmatically) explore, monitor, and change specific values dynamically like custom fan control. There's also the sysctl and config if you need bulk/one time changes. I wonder what FreeBSD's reason was to disable procfs (last time I checked it was disabled and not removed).

    Leave a comment:

Working...
X