Difference between revisions of "Linux development process"

From Gender and Tech Resources

m
m
 
(30 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
Jessie installs systemd by default on new installs. This lack of choice is against point 4 of the Debian Social Contract https://www.debian.org/social_contract.en.html. And not only that: http://ewontfix.com/14/:
+
From the perspective of a linux distro, ''upstream'' usually refers to the original author(s) of the source code for a particular package. Downstream may refer to a distribution that has forked/branched from the perspective of the distro you are looking at.
  
−
''So how should init be done right?''
+
So if Debian receives a bug relating to Apache, then a package maintainer or anyone reading the bugs may do some investigation. If they determine the bug to be in the original source code, and not caused by something unique to the distro they will work with the upstream authors to work on fixing the bug in program.
  
−
''The Unix way: with simple self-contained programs that do one thing and do it well.
+
If the upstream developer of the troublesome package is uncooperative or went awol, then the investigating developer may add a patch to the package. This can be seen as a (hopefully temporary) fork of upstream development. Once bug and maintainer are found and bug is solved, Debian may work with ''downstream'' distros like Ubuntu to make sure the bug is fixed everywhere. Downstream maintainers can also submit issues related to things having to do with a packaging or any patches added.
−
''
+
−
''First, get everything out of PID 1:
+
−
''
+
−
* ''The systemd way: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described in http://ewontfix.com/14/ (and probably many more yet to be discovered).''
+
−
* ''The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies:''
+
  
−
''Next, from the init script, run a process supervision system outside of PID 1 to manage daemons as immediate child processes (no backgrounding). As mentioned above are several existing choices here. It's not clear to me that any of them are sufficiently polished or robust to satisfy major distributions at this time. But neither is systemd; its backers are just better at sweeping that under the rug.''
+
If we are working on something like mint, which is based on ubuntu, which in turn is based on debian, the term upstream could mean any one of the maintainers of mint, ubuntu and debian, or it could refer to the original author(s) of a package. When maintainers and author(s) of packages are working well together usually all of them will be subscribed to similar lists, and bugtrackers and anyone with some responsibility for a given package will be notified in some form about bugs and new patches made at any level.
  
−
''What the existing choices do have, though, is better design, mainly in the way of having clean, well-defined scope rather than Katamari Damacy http://en.wikipedia.org/wiki/Katamari_Damacy.''
+
== Kernel development ==
  
−
''If none of them are ready for prime time, then the folks eager to replace legacy init in their favorite distributions need to step up and either polish one of the existing solutions or write a better implementation based on the same principles. Either of these options would be a lot less work than fixing what's wrong with systemd.''
+
On occasion code is merged into the upstream kernel, the kernel tree managed by Linus Torvalds and available from kernel.org.
  
−
''Whatever system is chosen, the most important criterion is that it be transparent to applications. For 30+ years, the choice of init system used has been completely irrelevant to everybody but system integrators and administrators. User applications have had no reason to know or care whether you use sysvinit with runlevels, upstart, my minimal init with a hard-coded rc script or a more elaborate process-supervision system, or even <code>/bin/sh</code>. Ironically, this sort of modularity and interchangibility is what made systemd possible; if we were starting from the kind of monolithic, API-lock-in-oriented product systemd aims to be, swapping out the init system for something new and innovative would not even be an option.''
+
Merging source code upstream takes effort, dedication and time. The threshold for getting source code accepted into the Linux kernel is relatively high. If bad quality code got accepted, maintaining the linux kernel would become much more difficult.
  
−
''There has been some interest in having a proper free software license on the trivial init code included above. I originally considered it too trivial to even care about copyright or need a license on it, but I don't want this to keep anyone from using or reusing it, so I'm explicitly licensing it under the standard MIT license'' ~ Rich Felker
+
== Package development ==
−
 
+
−
Thankies dear.
+
−
 
+
−
[[File:Dontpanic.jpg|640px|thumb|right]]
+
−
 
+
−
== Init ==
+
−
 
+
−
<pre>#define _XOPEN_SOURCE 700
+
−
#include <signal.h>
+
−
#include <unistd.h>
+
−
 
+
−
int main()
+
−
{
+
−
    sigset_t set;
+
−
    int status;
+
−
 
+
−
    if (getpid() != 1) return 1;
+
−
 
+
−
    sigfillset(&set);
+
−
    sigprocmask(SIG_BLOCK, &set, 0);
+
−
 
+
−
    if (fork()) for (;;) wait(&status);
+
−
 
+
−
    sigprocmask(SIG_UNBLOCK, &set, 0);
+
−
 
+
−
    setsid();
+
−
    setpgid(0, 0);
+
−
    return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
+
−
}</pre>
+
−
 
+
−
''Yes, that's really all that belongs in PID 1. Then there's no way it can fail at runtime, and no need to upgrade it once it's successfully running.''
+
−
 
+
−
== Threading carefully ==
+
−
 
+
−
=== Exception handling ===
+
−
 
+
−
=== Initialisation ===
+
−
 
+
−
==== Mounting virtual file systems ====
+
−
 
+
−
==== Setting hostname ====
+
−
 
+
−
==== Kill ====
+
−
 
+
−
Sending SIGTERM to processes
+
−
 
+
−
Sending SIGKILL to processes
+
−
 
+
−
==== Mounting real file systems ====
+
−
 
+
−
Mounting local file systems
+
−
 
+
−
Unmounting real file systems
+
−
 
+
−
==== Managing temporary files ====
+
−
 
+
−
==== Daemons ====
+
−
 
+
−
<code>eudev</code> is a fork of systemd-udev with the goal of obtaining better compatibility with existing software such as OpenRC and Upstart, older kernels, various toolchains and anything else required by users and various distributions.
+
−
 
+
−
In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99 while tracking closely the systemd-udev developments https://wiki.gentoo.org/wiki/Project:Eudev
+
−
 
+
−
Starting uedev deamon
+
−
 
+
−
Triggering uedev events
+
−
 
+
−
Waiting for uedev events to be processed
+
−
 
+
−
Shutting down uedev deamon
+
−
 
+
−
==== Auto grouping ====
+
−
 
+
−
==== Socket activation ====
+
  
 
== Resources ==
 
== Resources ==
−
 
+
=== Kernel ===
 
* A Guide to the Kernel Development Process http://www.linuxfoundation.org/content/1-guide-kernel-development-process
 
* A Guide to the Kernel Development Process http://www.linuxfoundation.org/content/1-guide-kernel-development-process
 +
* The Linux Kernel Archives https://www.kernel.org/
 +
* The kernel guide http://www.linux.org/threads/linux-kernel-reading-guide.5384/
 +
* LinuxChanges http://kernelnewbies.org/LinuxChanges
  
 
== Related ==
 
== Related ==
 
* [[Captivating capital and copyfighting]]
 
* [[Captivating capital and copyfighting]]
 +
* [[A typical linux distribution]]
 +
* [[Linux virtualisation]]
 +
* [[Making our own linux images]]
 
* [[Installing linux]]
 
* [[Installing linux]]
 
* [[Linux applications]]
 
* [[Linux applications]]
  
 
== References ==
 
== References ==

Latest revision as of 14:55, 11 August 2015

From the perspective of a linux distro, upstream usually refers to the original author(s) of the source code for a particular package. Downstream may refer to a distribution that has forked/branched from the perspective of the distro you are looking at.

So if Debian receives a bug relating to Apache, then a package maintainer or anyone reading the bugs may do some investigation. If they determine the bug to be in the original source code, and not caused by something unique to the distro they will work with the upstream authors to work on fixing the bug in program.

If the upstream developer of the troublesome package is uncooperative or went awol, then the investigating developer may add a patch to the package. This can be seen as a (hopefully temporary) fork of upstream development. Once bug and maintainer are found and bug is solved, Debian may work with downstream distros like Ubuntu to make sure the bug is fixed everywhere. Downstream maintainers can also submit issues related to things having to do with a packaging or any patches added.

If we are working on something like mint, which is based on ubuntu, which in turn is based on debian, the term upstream could mean any one of the maintainers of mint, ubuntu and debian, or it could refer to the original author(s) of a package. When maintainers and author(s) of packages are working well together usually all of them will be subscribed to similar lists, and bugtrackers and anyone with some responsibility for a given package will be notified in some form about bugs and new patches made at any level.

Kernel development

On occasion code is merged into the upstream kernel, the kernel tree managed by Linus Torvalds and available from kernel.org.

Merging source code upstream takes effort, dedication and time. The threshold for getting source code accepted into the Linux kernel is relatively high. If bad quality code got accepted, maintaining the linux kernel would become much more difficult.

Package development

Resources

Kernel

Related

References

Retrieved from "https://gendersec.tacticaltech.org/wiki/index.php?title=Linux_development_process&oldid=4970"