User: Password:
|
|
Subscribe / Log in / New account

There are real reasons to question systemd

There are real reasons to question systemd

Posted Jan 28, 2013 16:16 UTC (Mon) by ebiederm (subscriber, #35028)
Parent article: Poettering: The Biggest Myths

Since no one has mentioned this.

FACT: systemd has had at least one well publicized failure to do the job it is responsible for so severe the linux kernel had to be changed because the systemd maintainers could not get their act together.


(Log in to post comments)

There are real reasons to question systemd

Posted Jan 28, 2013 17:52 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

Here's another FACT: the kernel broke API more than once so that systemd broke too, even though the kernel folks consider breaking userspace a total no-no. Also FACT: one thing that broke systemd was namespacing code, the removal of "nspid". Namespacing is what a certain "ebiederm" hacked on.

There are real reasons to question systemd

Posted Jan 29, 2013 11:27 UTC (Tue) by nix (subscriber, #2304) [Link]

You can't break userspace! for values of 'userspace' equal to 'the syscall API'. What, you're using something the kernel exports other than syscalls? Sucks to be you, expect repeated breakage :( (though the churn has slowed somewhat in the last few years, thank goodness.)

Breaking userspace

Posted Jan 29, 2013 13:12 UTC (Tue) by eru (subscriber, #2753) [Link]

I recently wrote some code that wants to know how many cores or processors there are in the Linux system, so it can estimate how many parallel threads it makes sense to set up. I did this by scanning "/proc/cpuinfo". Is this now in danger of breaking at any time, because it relies on "something the kernel exports other than syscalls?"

In that case I would like to know of some alternate, more stable way to get this information - and preferably without adding dependencies on some heavy-duty libraries or middleware, since the program currently depends on nothing but its own code, the standard C library, and pthreads.

Breaking userspace

Posted Jan 29, 2013 13:45 UTC (Tue) by cortana (subscriber, #24596) [Link]

Breaking userspace

Posted Jan 29, 2013 13:53 UTC (Tue) by khim (subscriber, #9252) [Link]

What's wrong with a standard C library?

Breaking userspace

Posted Jan 29, 2013 16:20 UTC (Tue) by nix (subscriber, #2304) [Link]

IIRC, that's actually never worked on all multi-CPU architectures: it just happens that x86 and x86_64 report one stanza per CPU.

Breaking userspace

Posted Jan 29, 2013 16:54 UTC (Tue) by cesarb (subscriber, #6266) [Link]

/sys/devices/system/cpu seems better, and looks the same at least on this desktop (x86-64) and my phone (arm).

Breaking userspace

Posted Jan 29, 2013 19:01 UTC (Tue) by nix (subscriber, #2304) [Link]

But that's /sys, which is also rather more mutable than the syscall interface.

getconf _NPROCESSORS_CONF (or _NPROCESSORS_ONLN) is the thing to use (or, from a program, sysconf(_SC_NPROCESSORS_CONF) et seq. This is in glibc, so has a stability guarantee that is worth something. Let it figure out where to go for the answer.

Breaking userspace

Posted Jan 29, 2013 20:10 UTC (Tue) by eru (subscriber, #2753) [Link]

Thanks nix, and khim, that looks like what I need.

Breaking userspace

Posted Jan 29, 2013 16:29 UTC (Tue) by cesarb (subscriber, #6266) [Link]

Copying an old Stack Overflow answer of mine:

The definitive resource for /sys is Documentation/sysfs-rules.txt. The definitive resource for /proc/sys is Documentation/sysctl/. The definitive resource for the rest of /proc appears to be Documentation/filesystems/proc.txt. The rest of the Documentation/ directory in the Linux kernel source has other interesting information. In particular, Documentation/ABI/ mentions the stability of each interface.

(Unfortunately for your use case, I found nothing about /proc/cpuinfo in these files, and I know that the output is very different depending on the architecture, so it is probably not stable. The /sys/devices/system/cpu directory has some of that information, however, including how many cores there are, and should be the same for all architectures, so I would recommend looking there first and using /proc/cpuinfo as a fallback.)

There are real reasons to question systemd

Posted Jan 29, 2013 12:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Would you mind telling us what those alleged kernel ABI breakages were?

There are real reasons to question systemd

Posted Jan 29, 2013 13:30 UTC (Tue) by lsl (subscriber, #86508) [Link]

Presumably files exported in sysfs. The very nature of sysfs makes keeping it stable an awkward task. As the first few lines in Documentation/sysfs-rules.txt say:

> The kernel-exported sysfs exports internal kernel implementation details
> and depends on internal kernel structures and layout. It is agreed upon
> by the kernel developers that the Linux kernel does not provide a stable
> internal API. Therefore, there are aspects of the sysfs interface that
> may not be stable across kernel releases.

There are real reasons to question systemd

Posted Jan 28, 2013 19:07 UTC (Mon) by smurf (subscriber, #17840) [Link]

(a) assuming that you talk about what I think you talk about, exactly whose failure it was is open to debate.

(b) not everybody religiously reads LWN and/or can read minds, so kindly name names.

Thank you.

There are real reasons to question systemd

Posted Jan 29, 2013 0:40 UTC (Tue) by robert_s (subscriber, #42402) [Link]

I've become awfully suspicious of the word FACT in capital letters.

There are real reasons to question systemd

Posted Jan 30, 2013 19:12 UTC (Wed) by ttelford (subscriber, #44176) [Link]

Depends on your source. Given a choice between ebiederm and any other human on the planet, I'll take ebiederm's word.

There are real reasons to question systemd

Posted Jan 30, 2013 19:45 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Facts are not a matter of taking anyones word about it, they are either true or not irrespective of human concerns or politics.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds