Status of LinuxPPS

Udo van den Heuvel asked for the status of LinuxPPS (Linux Pulse Per Second): Why was it being rejected for inclusion in the kernel? Alan Cox and Andrew Morton scratched their heads and said they couldn't remember what if any objection anyone had had to the code. They both suggested resubmitting it because that would trigger any remaining alarm bells that had ceased to echo in the minds of anyone who cared.

The LinuxPPS (http://wiki.enneenne.com/index.php/LinuxPPS_support) API provides an interface between kernel and user space across character devices. A couple of weeks after that little exchange, Rudolfo Giometti submitted the core LinuxPPS code for inclusion. His idea was to make sure everyone signed off on the basic features; at least then there would be a big wad of code in the kernel for the PPS developers to add onto piecemeal.

At this point Andrew asked Rudolfo to explain which ancient objections, if any, remained unaddressed in the code. But Alan said he certainly liked this latest version. In response to Andrew, Rudolfo said he had fixed all objections, the sole objection being something from "George Spelvin" that all parties had agreed could wait until later. With no further debate on the issue, it seems likely that LinuxPPS – at least the core code – will soon be merged.

PMM

Michal Nazarewicz announced PMM (Physical Memory Management), code that allows users to allocate large contiguous regions of physical memory. For Michal at Samsung, this allowed him to decode and scale JPEG images and pass the scaled images to an X server, minimizing memory usage and increasing efficiency. Peter Zijlstra remarked that this might be all well and good, but if no contiguous regions of memory were available for allocation, Michal's PMM code would fall down flat. After a short bit of uptime, few systems would have any large contiguous areas of RAM to choose from. Michal replied that PMM reserved a large pool of RAM at boot time and allocated memory from the pool as needed. Peter asked how Michal would stop the PMM reserved RAM area from fragmenting as it is used. Michal replied that different use cases would result in fragmentation and the only sure way to avoid this would be to increase the size of the RAM pool reserved at boot time. But that was not so scalable. PMM, Michal said, was an attempt to find a compromise between the various needs of the running system. But, Andrew Morton remarked, "We do have capability in page reclaim to deliberately free up physically contiguous pages (known as "lumpy reclaim"). It would be interesting were someone to have a go at making that available to userspace." Michal grabbed hold of that idea and started a technical discussion about its feasibility. It does seem that in its current form, PMM would not be acceptable in the kernel because of the very restricted and specialized use case it represents.

In-Kernel Debugger Status

Jason Wessel proposed unifying KDB and KGDB, essentially making KDB a front end to KGDB. He tried to put the idea as delicately as he could, asking whether the KDB folks would still find value in such a project. He posted some patches along the lines of what he had in mind. Maxim Levitsky and Louis Rilling both jumped up to say that they liked KDB and would definitely love to see it in the kernel. Christoph Hellwig also expressed enthusiasm for the idea, adding that making KDB a front end to KGDB would be fine with him. Martin Hicks was also excited about this prospect. In this thread at least, the consensus seemed to be that having a native kernel debugger would be excellent and merging KDB and KGDB in the way Jason suggested would also be excellent. On the other hand, Linus Torvalds has resisted including a native debugger in the kernel, and he certainly won't want to let a new front end in until his own objections are addressed. A week or so later, Jason posted more patches, and Ingo Molnár offered some fairly invasive criticisms, remarking, "I supported and helped a debugging back end and I don't consider a front end completely impossible either. But it will have to meet a lot of stringent standards because a good kernel debugging front end's cross section to the system is even larger than a back end's. It's a tough job to get this done." Jason responded with an attempt to address some of Ingo's objections, but a big effort will have to be put into this before it will make it into the kernel.