<?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: Notes on OpenBSD device drivers</title>
	<atom:link href="http://thetarpit.org/2022/notes-on-openbsd-device-drivers/feed" rel="self" type="application/rss+xml" />
	<link>http://thetarpit.org/2022/notes-on-openbsd-device-drivers</link>
	<description>"Now I feel like I know less about what that blog is about than I did before."</description>
	<pubDate>Sat, 25 Apr 2026 17:30:40 +0000</pubDate>
	<generator>http://thetarpit.org</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: spyked</title>
		<link>http://thetarpit.org/2022/notes-on-openbsd-device-drivers#comment-3462</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sat, 19 Nov 2022 16:45:17 +0000</pubDate>
		<guid isPermaLink="false">http://thetarpit.org/?p=482#comment-3462</guid>
		<description>I'm not sure what weight algorithmic complexity bears in all this.

A quick grep for DV_TAPE reveals that it's used in sys/kern/subr_autoconf.c (autoconf glue code for hibernation? not sure) and otherwise the only driver defined as "tape" is the SCSI tape driver in sys/scsi/st.c. Not to underplay the role of tape devices, but my guess is they could have given up the tape classification in st.c and refactored the piece in subr_autoconf.c (which doesn't seem to have a place there anyway), it just wasn't a priority... and probably the next OpenBSDer will invite me to have a shot at it, which is a fair point after all, as the thing is "open sores".

Anyway, I think the only meaningful distinction is between block and char devices, and that's defined somewhere else. I guess that'd make a good next post in this series.</description>
		<content:encoded><![CDATA[<p>I'm not sure what weight algorithmic complexity bears in all this.</p>
<p>A quick grep for DV_TAPE reveals that it's used in sys/kern/subr_autoconf.c (autoconf glue code for hibernation? not sure) and otherwise the only driver defined as "tape" is the SCSI tape driver in sys/scsi/st.c. Not to underplay the role of tape devices, but my guess is they could have given up the tape classification in st.c and refactored the piece in subr_autoconf.c (which doesn't seem to have a place there anyway), it just wasn't a priority... and probably the next OpenBSDer will invite me to have a shot at it, which is a fair point after all, as the thing is "open sores".</p>
<p>Anyway, I think the only meaningful distinction is between block and char devices, and that's defined somewhere else. I guess that'd make a good next post in this series.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cel Mihanie</title>
		<link>http://thetarpit.org/2022/notes-on-openbsd-device-drivers#comment-3460</link>
		<dc:creator>Cel Mihanie</dc:creator>
		<pubDate>Sat, 19 Nov 2022 14:50:18 +0000</pubDate>
		<guid isPermaLink="false">http://thetarpit.org/?p=482#comment-3460</guid>
		<description>Well technically speaking, tape seeking is O(N) and disk seeking is ~O(1), or if you wanna be really pedantic, O(N^-k) with k between 2..4 :P Then again, this distinction is of interest to the driver's upstream users, not necessarily to the driver itself.

Historical reasons might indeed be the best explanation for that classification tho. It looks like a list of the devices that would have been available in the early 90s. And indeed, the file history shows the list was in this form around 1993..1994 and never modified since.</description>
		<content:encoded><![CDATA[<p>Well technically speaking, tape seeking is O(N) and disk seeking is ~O(1), or if you wanna be really pedantic, O(N^-k) with k between 2..4 :P Then again, this distinction is of interest to the driver's upstream users, not necessarily to the driver itself.</p>
<p>Historical reasons might indeed be the best explanation for that classification tho. It looks like a list of the devices that would have been available in the early 90s. And indeed, the file history shows the list was in this form around 1993..1994 and never modified since.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
