Simon:
What’s your ultimate goal? Writing programs for Linux systems? Or is the goal, specifically, learning the Linux API?
If it’s the first, just writing programs: forget about Linux API. Just pick up your favourite language and use its libraries. Trying to write any bigger program directly using system’s facilities is going to be royal pain. Not only due to the amount of doing-nothing code to write, but also from risks associated: misuse of the features,
(1) much larger bug-spawning areas, and — if some “deeper magic” is used — stability.
(2) If that is going to be a fully-fledged modern application, you may already have enough of other things to master (like dbus, Freedesktop specs, integration with existing services &c.)
If you must extend your program beyond what libraries may offer, then it may be worth going for system facilities. But for this you don’t need to know all of them. Just the particular topic and its surroundings. And these you may learn, when needed. The few basic topics, which IMO are shared among most features, are:
- File descriptors (open, read, write, …): most things are using streams as the underlying abstraction.
- Signals: even if not used directly, they do afffect many other calls.
- Threads (pthread_*): same as above.
- Process management (fork, exec*, wait, …): critical to understanding interactions between various things, when multiple processes are used
- procfs and sysfs: many, many things may rely on the information there.
- Namespaces and cgroups: you may not need to use these directly, but they may affect your program. Best approached from the perspective of the user/admin (e.g. through their use in systemd), as the theoretical, system-side view is complicated, hardly meaningful, and still quite unstable.
You will also encounter
fcntl often, but this is not something that can be learned in isolation.
If the answer is the latter, learning system facilities per-se, then don’t learn all of them. Or at best skim over the concepts to just know they are there and what they are about. But focus only on the few selected topics, which are of interest to you. Maybe try writing some programs, that use them, and then use the book to solve the problem.
If you need additional resources, I can’t offer many anymore. But certainly you should see the ever-current classic from Beej:
Beej’s Guide to Network Programming. There is also a guide to IPC: not as legendary, but gives equally easy access to the topic.
Always search the internet for comments on the facilities. What seems very obvious may not be as simple, and nuances are way too easy to miss. What you used/learned 2 years earlier may be superseded or acquire new, unexpected behavior.
Of course you may be the kind of a person, who just reads reference books back-to-back. Nothing wrong with that and I agree it gives great overview of a topic as a whole. Guess how I know
. But I guess you wouldn’t start this thread, if that was the case, and certainly this is not an efficient method of learning stuff.
(1) In particular these related to very low-level stuff. Sometimes even hardware level. There are dragons out there, which 99% of programmers got completely wrong. And that despite warnings in the documentation and even rudimentary Stack Overflow results suggesting, that the there is something wrong with their understanding.
(2) Linux APIs, in particular thes aligned with POSIX, are stable, when you rely on their basic semantics. As soon as you start playing with “may”, “might”, “could”, “optionally”, and various “heavy wizardry”, the features become more and more influenced by the environment, configuration, kernel version, and phase of the moon. Even if the facility itself is stable, what world demands from you may be not. Forcing you to rewrite low-level code just to adjust to current standards.
Home
Help
Search
Login
Register
