Zack's Kernel News
Video-4-Linux Docs Made XHTML Compliant
Németh Márton updated the V4L documentation to be XHTML compliant. A benefit of this is that the file can be parsed and any useful data snarfed into some other application. I'm not sure whether any other applications would have use for that, but Németh has made the possibility available.
Tracking Pesky Daemons
Scott James Remnant has written a bit of code to shed some light on daemon behavior. Currently, a process daemonifies by forking a child and then exiting. The child is then reparented to the init process (the parent of all processes), where the child detaches itself from the terminal that invoked the daemon. The child then forks again and exits, essentially leaving a grandchild of the original process. This grandchild is reparented to the init process and performs all the tasks ofthe daemon. This happens every time you invoke a daemon: Fork, fork, and the resulting child sits on the system as a child of init.
The problem Scott wanted to address was that this daemon has been so completely disconnected from the process that started it, there is no way for init to associate it with that process. When the daemon dies, init will have no way of knowing that this was the process associated with the invocation that happened earlier. Among other issues, this makes it difficult to create meaningful system logs. It would be nice to be able to go through the logs and see the different parts of a service all logged together.
One way Scott found to keep track of the relationships between the original process and the daemon it leaves behind is to have init do a ptrace() on all processes; however, this has a number of drawbacks, including security issues, as well as causing some software to change its behavior precisely because it's running in ptrace()! No good.
The solution Scott proposes is to create a couple of new signals, specifically to handle this reparenting-to-init situation, that will carry information to init about the lineage of the children being reparented to it. Scott says this wouldn't require any changes to user code or cause software to behave differently under Linux than it would under other operating systems; it would just keep track of the reparenting side of things in a way that lets init associate child processes with their dead parents.
Nick Warne has been running Slamd64 (http://www.slamd64.com/), an x86 64-bit system, for a while and thought that the time was ripe for a new framebuffer boot logo for the system. He submitted his own creation: http://www.nick.ukfsn.org/stuff/logo_linux64_clut224.ppm. Sadly, it wasn't tremendously well received. Some folks just didn't like it, whereas others had logos of their own to suggest. Markus Reichelt posted a link to his own creation at: http://mareichelt.de/temp/logo_linux_clut224.ppm. Folks reaching consensus didn't seem likely, but it does help illustrate the progress of 64-bit x86 systems lately.
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?