
Journal phantomfive's Journal: Systemd (or, how to make portable software) 10
In this post, Lennart explains that he doesn't know how to write portable C code. He says:
[Making systemd portable] would turn every second line of systemd into #ifdefs.
The purpose of my post here is to explain how to write portable code, without #ifdefs on every other line. If that happens, you are doing it the hard way.
An easier way is to create an OS independent layer. Call it OSI (since no one is using that acronym anymore, right?). Create a header file that declares all your functions, then create an implementation file for each platform. Every time you find a piece of functionality that is different on different platforms, throw it into that header file.
For example, if you need to take a screenshot, it will be different on every platform you find. In the header file, create a function OSI_Screenshot(). Then in your OSI_Windows.c file, add an implementation for windows. In your OSI_Linux.c, add a screenshot implementation for Linux. In your OSI_OSX.c, add your implementation for OSX. This technique can also work for extremely incompatible platforms, with OSI_printf(), or OSI_malloc(), etc. If you use your compiler correctly, you can compile it without any extra overhead from the function call.
An example of this technique can be found in Android (look at sysdeps.h and sysdeps_win32.c), demonstrating that this technique works. They don't have #ifdefs scattered throughout their code. The Android example is tougher than it needs to be, because Android added the compatibility layer after the code was written. If they had started at the beginning, the code would have been much simpler.
The lack of knowledge (about how to write portable code) in the systemd team is causing them to make bad decisions, because the alternative seems too hard. For example:
I have no plans porting it to other kernels, and I will not merge any such patches........Quite frankly, I'd like to question [cross-platform compatibility]. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore.
Those who don't understand the failures of the past are destined to repeat them. Plenty of vendors try to focus on a single platform, and their work disappeared, to be replaced by something that was cross-platform compatible, and usually better work. The discipline required to keep things portable results in better code (there's a quote from Mythical Man Month that fits here but I'm too lazy to look it up). The Gnome developers understand the importance of portability but that's a story for another post.
MMM (Score:2)
Bach's creative output hardly seems to have been squelched by the necessity of producing a limited-form cantata each week. I am certain that the Stretch computer would have had a better architecture had it been more tightly constrained.(47)
Another tip for avoiding #ifdefs (Score:2)
#define FEATURE_ENABLED 1
if(FEATURE_ENABLED) {
call_feature_function();
}
else {
call_non_feature_function();
}
The compiler will completely optimize out the if statement here (just as slashdot optimized out my spaces).
ecode (Score:1)
just as slashdot optimized out my spaces
You want:
<ecode>
</ecode>
Re: (Score:2)
cgroups (Score:1)
The main reason systemd isn't portable to non-linux systems is cgroups.
cgroups is a linux-kernel only feature. No amount of #ifdef magic is going to let you get around that.
No cgroups, no systemd.
Re: (Score:2)
- cgroups
- timerfd
- signalfd
- epoll
- autofs4
- inotify
- fanotify
-
-
-
- libudev
- POSIX mqueue as fd
- AF_UNIX/SOCK_SEQPACKET
- abstract namespace AF_UNIX
- g
Re: (Score:1)
gnome doesn't depend on cgroups. It doesn't depend on systemd either.
systemd does depend on cgroups -- systemd's whole raison d'etre is to be a service manager that knows exactly what processes belong to what services. (and, other fun stuff like limiting resource usage on a per service basis).
Now I do see some FreeBSD people claiming that it has a cgroups equivalent interface, see https://news.ycombinator.com/item?id=8355330 [ycombinator.com] for example.
I wonder how different it is?
Maybe if someone wants to implement syst
Re: (Score:2)
gnome doesn't depend on cgroups. It doesn't depend on systemd either.
Well, it does, but it's a soft dependency (can be replaced by other things). So whatever word you want to use for that is fine.
-- systemd's whole raison d'etre is to be a service manager that knows exactly what processes belong to what services. (and, other fun stuff like limiting resource usage on a per service basis).
I don't know if 'raison d'etre' is the right word here, since there are many potential reasons it could exist......but the reason it's been adopted is primarily because it makes it easier to write init scripts. That's really all people really seem to want (there are some other interesting ideas in systemd, like a unified API for accessing USB but IMO that is utterly useless without
Re: (Score:2)
The good news is that even without updating your sig, everyone on your fan list [slashdot.org] just got a message saying 'New Journal Entry by phantomfive, "Systemd (or, how to make portable software)" [X]', so you will still get some traction from that. (That's how I got here...)
Re: (Score:2)