<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 2010/01/17 Linux Kernel Podcast</title>
	<atom:link href="http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/</link>
	<description>A semi-daily summary of LKML traffic</description>
	<lastBuildDate>Tue, 13 Jul 2010 23:19:22 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Anon</title>
		<link>http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/comment-page-1/#comment-1402</link>
		<dc:creator>Anon</dc:creator>
		<pubDate>Mon, 25 Jan 2010 23:13:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.kernelpodcast.org/?p=469#comment-1402</guid>
		<description>Jan 25th
utrace. This is an interface designed to provide better/cleaner tracing support for userspace that ptrace. Submission was originally attempted by Frank Ch. Eigler on the 19th January and has since drawn the attention of many developers wandering about its usefulness. Linus Torvalds replied arguing that the utrace developers were arguing the wrong way for its inclusion and this has resulted in its overdesign. The thread detoured as Ingo Molnar explained how features that had started life in the -rt tree had been improved and made more palatable for general use, resulting in mainline adopting said features.

http://thread.gmane.org/gmane.linux.kernel.utrace/3258/focus=10941</description>
		<content:encoded><![CDATA[<p>Jan 25th<br />
utrace. This is an interface designed to provide better/cleaner tracing support for userspace that ptrace. Submission was originally attempted by Frank Ch. Eigler on the 19th January and has since drawn the attention of many developers wandering about its usefulness. Linus Torvalds replied arguing that the utrace developers were arguing the wrong way for its inclusion and this has resulted in its overdesign. The thread detoured as Ingo Molnar explained how features that had started life in the -rt tree had been improved and made more palatable for general use, resulting in mainline adopting said features.</p>
<p><a href="http://thread.gmane.org/gmane.linux.kernel.utrace/3258/focus=10941" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.utrace/3258/focus=10941</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anon</title>
		<link>http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/comment-page-1/#comment-1360</link>
		<dc:creator>Anon</dc:creator>
		<pubDate>Mon, 18 Jan 2010 22:38:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.kernelpodcast.org/?p=469#comment-1360</guid>
		<description>User Space Breakpoints. Discussion between Avi Kivity and other kernel developers continues over the introduction of infrastructure for faster uprobes. Avi pointed out that if the address space could not be changed the alternatives (emulation and single stepping) would be much slower. Pekka Enberg enquired as to the amount of address space that would be lost. Avi replied it would be 32 bytes per probe so 32Mbytes would give a million probes which was an insignificant amount for x86_64 but might be more of a problem on i386.</description>
		<content:encoded><![CDATA[<p>User Space Breakpoints. Discussion between Avi Kivity and other kernel developers continues over the introduction of infrastructure for faster uprobes. Avi pointed out that if the address space could not be changed the alternatives (emulation and single stepping) would be much slower. Pekka Enberg enquired as to the amount of address space that would be lost. Avi replied it would be 32 bytes per probe so 32Mbytes would give a million probes which was an insignificant amount for x86_64 but might be more of a problem on i386.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anon</title>
		<link>http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/comment-page-1/#comment-1359</link>
		<dc:creator>Anon</dc:creator>
		<pubDate>Mon, 18 Jan 2010 22:24:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.kernelpodcast.org/?p=469#comment-1359</guid>
		<description>Workqueue simplification. Tejun Heo posted a series of patches simplifying usage of workqueues and introducing workqueues where multiple shared workers are available per cpu. Arjan objected to to the conversion of async thread pool to the new workqueue implementation because he wanted to keep the cookie and synchronisation mechanism.</description>
		<content:encoded><![CDATA[<p>Workqueue simplification. Tejun Heo posted a series of patches simplifying usage of workqueues and introducing workqueues where multiple shared workers are available per cpu. Arjan objected to to the conversion of async thread pool to the new workqueue implementation because he wanted to keep the cookie and synchronisation mechanism.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: abadidea</title>
		<link>http://www.kernelpodcast.org/2010/01/18/20100117-linux-kernel-podcast/comment-page-1/#comment-1352</link>
		<dc:creator>abadidea</dc:creator>
		<pubDate>Mon, 18 Jan 2010 12:39:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.kernelpodcast.org/?p=469#comment-1352</guid>
		<description>tyop report: s/are want to do/are wont to do/

(Yes, it is one of the weirdest words in the English language.)</description>
		<content:encoded><![CDATA[<p>tyop report: s/are want to do/are wont to do/</p>
<p>(Yes, it is one of the weirdest words in the English language.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
