Constantine A. Murenin

quotes of the week, or, Project-Sponsored Health Care

2009-08-23T17:26:39Z

Subject: Re: Common interface for sensors/health monitoring

The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices.

http://lists.freebsd.org/pipermail/freebsd-hackers/2009-August/029340.html

In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me!
I want all my individual events to be lost After I get them.
It's my right!

http://lists.freebsd.org/pipermail/freebsd-hackers/2009-August/029352.html

bash.org.ru

2008-05-21T03:56:19Z

Дело происходит в University of Ottawa.

Суббота, 2008-05-17, около 11:25 северо-американского восточного времени.

Подхожу к зданию SITE. Захожу в аудиторию G. В аудитории полно народу, включая phk и matthieu, сидящие в одном ряду друг напротив друга (позже оказалось, что места были выбраны из корыстных соображений, дабы получить доступ к розеткам, которые были в ограниченном доступе). Быстро пытаюсь найти кого-нибудь с расписанием. Смотрю — на последнем ряду как раз сидит тов. Тарасов. Подхожу, вглядываюсь в его монитор, спрашивая, чей Talk здесь сейчас будет, одновременно с этим замечая открытый браузер с bash.org.ru. “Твой!”, — недоумённо отвечает тов. Тарасов…

…

Выступление прошло довольно благополучно, несмотря на то, что из-за переезда мне не удалось портировать парочку драйверов под DragonFly и FreeBSD (и даже под lm_sensors, а вот под NetBSD km(4) в портировании уже не нуждается :), наличие которых должно было бы добавить несколько ещё более интересных аргументов в пользу предыдущей деятельности и объективности.

Выступление началось где-то в 11:32/33. Выступал как минимум 45 минут, насколько я помню. Потом пришёл слайд с вопросами и комментариями. “Any questions or comments?” Разумеется, phk не ушами пришёл хлопать, и сразу выступил в роли волонтёра с комментариями по озвучиванию своей позиции.

Кстати, забегая пару дней до этого, я всё-таки в конце концов решил посетить FreeBSD Developer Summit. Решил вести себя прилично и объективно, про hardware sensors упомянув только в "introduce yourself", и без лишнего озвучивания моего статуса в OpenBSD. Являясь товарищем довольно скромным, никого кроме своего соседа на talk не приглашал, но народу пришло хоть отбавляй. matthieu предположил, что это, в общем, и не является чем-то удивительным, учитывая популярность темы в списках рассылок FreeBSD. :-)

В общем, phk озвучил свою точку зрения, мы немного побеседовали, я у него спросил, почему он не против coretemp(4) и k8temp(4) во FreeBSD, пару товарищей задала ещё парочку небольших вопросов (будет ли поддержка нескольких уровней настроек в sensorsd; относится ли данный каркас приложений исключительно к i2c), и выступление было завершено ровно в 12:30. Всё выступление должно было быть записано на аудио, но неизвестно, будет ли это доступно где-либо, т.к. записи делались и на предыдущих конференциях, но до сих пор нигде не опубликованы. Dan подтвердил, что у него есть / будут записи, но сказал, что обещать ничего не будет.

сообщение

2007-10-14T23:45:07Z

сообщаю, что интерфейс для снятия показаний с датчиков был сегодня добавлен во FreeBSD 8.0-CURRENT

http://lists.freebsd.org/pipermail/cvs-src/2007-October/082381.html — framework
http://lists.freebsd.org/pipermail/cvs-src/2007-October/082382.html — it(4) and lm(4)
http://lists.freebsd.org/pipermail/cvs-src/2007-October/082383.html — coretemp(4)

напоминаю, что ранее данный интерфейс уже был добавлен в DragonFly BSD 1.11-DEVELOPMENT

http://leaf.dragonflybsd.org/mailarchive/commits/2007-10/msg00015.html — framework
http://leaf.dragonflybsd.org/mailarchive/commits/2007-10/msg00016.html — coretemp(4)
http://leaf.dragonflybsd.org/mailarchive/commits/2007-10/msg00017.html — it(4) and lm(4)

за подробной информацией прошу обращатся по адресу
http://wiki.freebsd.org/GSoC2007/cnst-sensors

GSoC2007: Программный интерфейс датчиков OpenBSD добавлен во FreeBSD 8.0-CURRENT

2007-10-14T23:32:18Z

Ранее мы уже сообщали о завершении работ по переносу каркаса приложений для датчиков из OpenBSD во FreeBSD, и о добавлении данного интерфейса в DragonFly BSD 1.11.

Сегодня Alexander Leidinger официально добавил патч Константина Муренина во FreeBSD 8.0-CURRENT. Были добавлены все основные компоненты проекта GSoC2007/cnst-sensors, включая sensor_attach(9), sysctl(3), sysctl(8), systat(1), sensorsd(8), а также драйверы it(4) и lm(4), и адаптация драйвера coretemp(4) под новый интерфейс.

Пользовательский интерфейс полностью совместим с OpenBSD и DragonFly BSD.

http://wiki.freebsd.org/GSoC2007/cnst-sensors

Программный интерфейс датчиков OpenBSD перенесён из FreeBSD в DragonFly BSD

2007-10-03T02:48:01Z

Ранее мы уже сообщали о завершении работ по переносу каркаса приложений для датчиков из OpenBSD во FreeBSD в рамках программы Google Summer of Code 2007.

Сегодня Hasso Tepper официально добавил несколько адаптированный патч Константина Муренина в DragonFly BSD 1.11. Были добавлены все основные компоненты проекта GSoC2007/cnst-sensors, включая sensor_attach(9), sysctl(3), sysctl(8), systat(1), sensorsd(8), а также драйверы coretemp(4), it(4) и lm(4).

Пользовательский интерфейс совместим с OpenBSD и FreeBSD.

GSoC2007: перенос программного интерфейса датчиков из OpenBSD во FreeBSD

2007-09-14T04:06:35Z

Константин Муренин сегодня объявил о завершении работ по переносу каркаса приложений для датчиков из OpenBSD во FreeBSD. Проект был осуществлён благодаря программе Google Summer of Code 2007.

Помимо driver API — sensor_attach(9) — были портированы sysctl(3), sysctl(8), systat(1) и sensorsd(8). Из драйверов пока были портированы it(4) и lm(4), которые вместе поддерживают почти все современные наборы логики Super I/O, производимые Winbond и ITE Tech.

Пользовательский интерфейс совместим с OpenBSD. Работа над проектом завершена, и товарищи, заинтересованные в его скорейшей интеграции в CVS HEAD, приглашаются к тестированию.

http://cnst.livejournal.com/38421.html#directions

GSoC2007.cnst-sensors.2007-09-13.patch

2007-09-13T22:53:41Z

		Google Summer of Code 2007 @ The FreeBSD Project
	Porting OpenBSD's sysctl Hardware Sensors framework to FreeBSD
			(2007-256, a 23-y.-o. edition)


Description:

	On this 256th day of 2007,   it is my great pleasure to
	present a feature-complete port of the hardware sensors
	framework from OpenBSD to FreeBSD.

	Below is a complete `cvs diff` of cnst-sensors GSoC2007
	project as of 2007-256.

	It includes the following components,  listed below in
	the very same order as they are appearing in this diff:

	* sample configuration file for sensorsd
	* rc(8) script and glue code for sensorsd(8)
	* sysctl(3) doc fixes for CTL_HW tree
	* sysctl(3) documentation for hardware sensors
	* sysctl(8) documentation for hardware sensors
	* assorted KNF and bug-fixes for sysctl(8)
	* support for the sensor structure for sysctl(8)
	* coretemp(4) documentation
	* it(4) documentation
	* lm(4) documentation
	* rc.conf(5) documentation for starting sensorsd(8)
	* sensor_attach(9) et al documentation
	* coretemp(4) conversion to the hw.sensors framework
	* it(4) isa driver ported from OpenBSD
	* lm(4) isa driver ported from OpenBSD
	* /sys/kern/kern_sensors.c
	  o sensor_attach(9) API for drivers to register ksensors
	  o sensor_task_register(9) API for the update task
	  o sysctl(3) glue code
	  o hw.sensors shadow tree for sysctl(8) internal magic
	* assorted KNF and bug-fixes for /sys/kern/kern_sysctl.c
	* it(4) module for testing sensor_attach/detach et al
	* lm(4) module for testing sensor_attach/detach et al
	* <sys/sensors.h>
	* assorted bug-fixes and HW_SENSORS definition for <sys/sysctl.h>
	* sensors display for systat(1), including all documentation
	* sensorsd(8) and all applicable documentation

	The userland part of the framework is entirely source-code
	compatible with OpenBSD 4.1, 4.2 and  -current as of today.

	All sensor readings can be viewed with `sysctl hw.sensors`,
	monitored in semi-realtime with `systat -sensors` and also
	logged with `sensorsd`.   Third-party tools, for example a
	plug-in for nagios, are also available.  A separate patch
	for ports/sysutils/symon will be provided upon request.

Exact directions on applying and testing:

cd /usr/src
fetch http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz
gunzip GSoC2007.cnst-sensors.2007-09-13.patch.gz
mkdir  sys/dev/{it,lm}  sys/modules/{it,lm}  usr.sbin/sensorsd
patch < GSoC2007.cnst-sensors.2007-09-13.patch

make -j128 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE="acpi it lm coretemp"
make installkernel KERNCONF=GENERIC MODULES_OVERRIDE="acpi it lm coretemp"

make includes

cd share/man/man4 && make && make install && make clean && cd ../../../
cd share/man/man5 && make && make install && make clean && cd ../../../
cd share/man/man9 && make && make install && make clean && cd ../../../

cd sbin/sysctl && make && make install && make clean && cd ../../
cd usr.bin/systat && make && make install && make clean && cd ../../
cd usr.sbin/sensorsd && make && make install && make clean && cd ../../

diff -u /boot/device.hints sys/`uname -m`/conf/GENERIC.hints
cat sys/`uname -m`/conf/GENERIC.hints >/boot/device.hints
cp etc/sensorsd.conf /etc/
shutdown -r now ; exit

...

OK load it
OK load lm
OK load coretemp
OK boot

...

sensorsd
sysctl hw.sensors
systat -sensors 1

12-year-old bug in FreeBSD's kern_sysctl.c

2007-09-03T19:58:50Z

The other week, I found a 12-year-old bug in FreeBSD's /sys/kern/kern_sysctl.c.

The bug is in the incorrect len parameter that is being passed to useracc(9).

I originally thought that it might have some security implications, but in reality, subsequent copyin(9) in sysctl_new_user() is supposed to take care of any boundary problems, so in the end, I'm not sure why this useracc(9) call is even there in the first place, buggy or not. ;)

Although fixing this bug so far doesn't seem to be of any real value to anyone -- tell me if it is to you -- it is nonetheless interesting to find bugs that were introduced so many years ago. ;)

Thanks to Robert Watson for taking his time to commit my patch and for the discussion. Here are some links to the mailing list regarding my fix being committed, read the message in the second link for my complete description of what the bug is about.

http://lists.freebsd.org/pipermail/cvs-src/2007-September/081597.html -- my patch is committed
http://lists.freebsd.org/pipermail/cvs-src/2007-September/081603.html -- my detailed comments

And here is the history of this bug:

http://cvsweb.freebsd.org/src/sys/kern/kern_sysctl.c#rev1.38 -- the bug is introduced in 1995
http://cvsweb.freebsd.org/src/sys/kern/kern_sysctl.c#rev1.91 -- the line with the bug is slightly altered
http://cvsweb.freebsd.org/src/sys/kern/kern_sysctl.c#rev1.177 -- the bug is fixed with my patch

I've also emailed Matt Dillon, and he committed my patch to DragonFly BSD, too:
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_sysctl.c#rev1.28 -- my patch in dragonfly

P.S. If you're actually looking for a useful but slightly younger bug that I've fixed, then look no further than in my “10-year-old pointer-arithmetic bug in make(1) is now gone…” entry. ;)

Best regards,
Constantine.

cnst-sensors.2007-08-20.patch

2007-08-21T03:52:51Z

http://p4web.freebsd.org/depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-08-20.patch

cd /usr/src
fetch http://p4web.freebsd.org/depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-08-20.patch
more cnst-sensors.2007-08-20.patch
mkdir  sys/dev/lm  sys/modules/lm  usr.sbin/sensorsd
patch < cnst-sensors.2007-08-20.patch

make buildkernel KERNCONF=GENERIC MODULES_OVERRIDE="acpi lm coretemp"
make installkernel KERNCONF=GENERIC MODULES_OVERRIDE="acpi lm coretemp"
make includes
cd share/man/man4 && make && make install && make clean && cd ../../../
cd share/man/man9 && make && make install && make clean && cd ../../../
cd sbin/sysctl && make && make install && make clean && cd ../../
cd usr.sbin/sensorsd && make && make install && make clean && cd ../../
cd usr.bin/systat && make && make install && make clean && cd ../../
diff -u /boot/device.hints sys/`uname -m`/conf/GENERIC.hints
cat sys/`uname -m`/conf/GENERIC.hints >/boot/device.hints
cp -p etc/sensorsd.conf /etc/
reboot

...

OK load lm
OK load coretemp
OK boot

...

sensorsd
systat -sensors 1

(these instructions were written and reproduced on a “tainted” machine, so if you find any errors, let me know)

coretemp(4) in FreeBSD

2007-08-19T03:26:11Z

Hurray, coretemp(4), a driver for monitoring Intel Core / Core 2 temperature, was recently imported into FreeBSD:
http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html — coretemp added to cvs

Obviously, I could not have ignored this opportunity, and this driver is now ported to sysctl hw.sensors framework, too:
http://lists.freebsd.org/pipermail/p4-projects/2007-August/020621.html — branch to cnst-sensors
http://lists.freebsd.org/pipermail/p4-projects/2007-August/020623.html — init sc_dev
http://lists.freebsd.org/pipermail/p4-projects/2007-August/020624.html — make get_temp more robust
http://lists.freebsd.org/pipermail/p4-projects/2007-August/020625.html — convert to sysctl hw.sensors

Taking the opportunity, I would like to express my thanks to rpaulo@ for his work and availability on IRC! :)

Committing things upstream

2007-08-18T17:44:51Z

Sometime during this Summer of Code, I felt a bit awkward on working on OpenBSD given that I am supposed to be porting stuff from OpenBSD to FreeBSD.

For example, if I find a bug or think about some new feature — should I fix it upstream in OpenBSD, or should I fix it in FreeBSD's sandbox (aka perforce) and leave for someone else to backport it to OpenBSD?

I was finally relived after some anonymous posters at undeadly.org and linux.org.ru on occasion commented whether the security things (e.g. the latest bug in named(8)) that are fixed in OpenBSD are committed upstream, and expressed their dismay if the answer was negative. (It must be noted that sometimes working with upstream isn't possible, as in this case of ISC's named, because upstream may not accept your fixes (e.g. for portability concerns), but that's a separate matter.)

As a matter of fact, on another occasion, OpenBSD's X.Org porter (aka xenocara author), matthieu@, said that he might have to run Linux for a few months in order to get all the new X.Org bugs fixed, as X.Org people don't take any non-Linux bug-reports seriously.

In conclusion: If you disapprove that someone who is porting a certain feature from one open-source project to another finds and fixes bugs in the original project, then you might want to consider talking to those anonymous posters to straighten your viewpoint. :) Or, as a matter of fact, to anyone who has had some experience with these dealings.

thoughts about bus_space_map(9) and bus_alloc_resource(9)

2007-08-06T05:30:17Z

For now, I'll just post a link and call it a day. Tomorrow, I'll see if I'd like to write something more about it, or just copy the text into my LJ. ;)

Any comments are welcome. (:

http://lists.freebsd.org/pipermail/p4-projects/2007-August/020363.html

Also, see http://cnst.livejournal.com/25342.html.

GSoC2007: cnst-sensors status update

2007-07-30T22:21:30Z

People interested in the recent status update regarding my project should refer to the following message:

http://lists.freebsd.org/pipermail/freebsd-arch/2007-July/006694.html

In brief: most things are fully functional but might need a bit further improvement in cutting rough edges. :) I will try see what can be done regarding sysctl(8) and sysctlbyname(3) in the following few days/weeks.

/sys/kern/kern_sysctl.c in FreeBSD

2007-07-25T21:59:38Z

I was looking at this code for a few minutes thinking how it could possibly continue working as opposed to generating oid_number clashes after a second OID_AUTO element is registered onto any given subtree, until it finally hit me. If you're not too intimate with C, trust me, this patch does not break the code flow in the simplest test case, although its effects on one's mind may vary greatly! :)

http://moduli.net/grok/diff/freebsd/src/sys/kern/kern_sysctl.c?r2=1.103&r1=1.102

--- src/sys/kern/kern_sysctl.c	2001/01/05 07:00:44	1.102
+++ src/sys/kern/kern_sysctl.c	2001/01/24 04:35:13	1.103
@@ -37,7 +37,7 @@
  * SUCH DAMAGE.
  *
  *	@(#)kern_sysctl.c	8.4 (Berkeley) 4/14/94
- * $FreeBSD: src/sys/kern/kern_sysctl.c,v 1.102 2001/01/05 07:00:44 jhb Exp $
+ * $FreeBSD: src/sys/kern/kern_sysctl.c,v 1.103 2001/01/24 04:35:13 mckusick Exp $
  */
 
 #include "opt_compat.h"
@@ -114,13 +114,11 @@ void sysctl_register_oid(struct sysctl_o
 	 * 100 to leave space for pre-assigned oid numbers.
 	 */
 	if (oidp->oid_number == OID_AUTO) {
-		/* First, find the highest oid in the parent list >99 */
-		n = 99;
-		SLIST_FOREACH(p, parent, oid_link) {
-			if (p->oid_number > n)
-				n = p->oid_number;
-		}
-		oidp->oid_number = n + 1;
+		static int newoid = 100;
+
+		oidp->oid_number = newoid++;
+		if (newoid == 0x7fffffff)
+			panic("out of oids");
 	}
 
 	/*

P.S. For the record, this patch did seem to generate some other problems, because it is based on certain assumptions that don't neccessarily hold, thus being less robust than what it has replaced. For example, see kern_sysctl.c#rev1.112.

2007-08-25 update: P.P.S. Whilst looking at some other issue, I've discovered that dillon@ actually backed out this mckusick's code from DragonFly, for the above reasons:
http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_sysctl.c#rev1.14

Koders.com now searches symon, too!

2007-07-12T19:55:52Z

symon is a system monitor for FreeBSD, NetBSD, OpenBSD and Linux.

I've briefly participated in the project when I've rewritten the sensors framework in OpenBSD, and someone told me that symon also required an upgrade in its platform/OpenBSD/sm_sensor.c module.

On 1st May 2007, I've submitted symon and OpenBSD to koders.com. Today on 12th July 2007, just a few minutes ago, I've received an email from koders.com that symon submission was accepted! Hurray!

I am now curious how much more time will it take until koders.com will approve OpenBSD's addition. If the size of the project directly influences the amount of time it takes for koders.com to approve the addition of the said project to their database, then we can expect OpenBSD to be added in merely a few years from now. ;)

…

Well, what can I say? I'm disappointed with koders.com. Even if we disregard this slowness in their addition of new projects, I've also discovered that they don't have usable URLs.

For example, I'm not sure that I can have a permanent link to the above module that I've contributed to — many of their URLs include useless information such as “default.aspx”, and all files appear to be referenced by some hashes, and I'm not sure that koders.com will keep these hashes from today compatible with their “default.aspx” of tomorrow.

There is even less certainty that they will keep their “default.aspx” tomorrow. ;)

cnst @ 2007-07-09T18:46:00

2007-07-09T22:51:12Z

23:08 < constant> just got back from a Western Union
23:08 < constant> received a whole pocket load of bills for my initial payment. :)
23:10 < constant> 14 bills in total! :)
23:10 < constant> at least, they didn't give me any coins. :)))
23:10 <@jbr> nice :)
23:10 <@jbr> i only got 3 bills and some coins :(
23:11 < constant> I'm curious how they are going to pay 2000 USD here. ;)
23:11 < constant> no way am I going to carry 100 bills! ;)
23:12 < constant> jbr: we you offered a cheque?
23:12 <@jbr> you should bring a briefcase, like in the movies
23:12 < constant> yeah, but in movies they have 100 USD bills. ;)
23:12 <@jbr> no, but i sure i could have gotten one, if i had asked
23:12 <@jbr> its the thought that counts ;)
23:13 < constant> for some reason here they print a cheque, and ask you to "endorse" it on the back, so that they can cash it
23:13 <@jbr> i like cash, for tax evasion purposes :)
23:13 < constant> I asked them if I can cash it myself, they said, "sure"
23:13 < constant> I went to the bank, but it was closed.
23:13 < constant> I looked more at the cheque, and noticed that it said, "Counter signature", but they didn't sign it
23:14 < constant> so I went back, asked them to sign it so that I won't have any problems at the bank -- they said they never sign them,
                  and offered to cash it instead.
23:14 < constant> so here I am, with 14 bills. :)
23:14 <@jbr> :)
23:15 < constant> jbr: cheques work for tax evasion purposes, too. :)
23:15 <@jbr> probably :)
23:15 < constant> btw, didn't have to bring any numbers with me, except for state-issued id
23:16 < constant> just wrote my address, said 500 USD, payment from Google, Inc from Mountain View, CA, USA, there it was

Porting means you get to find bugs in original implementation!

2007-07-01T23:01:49Z

The fun part about porting is that sometimes you get so intimate with the code that you undoubtedly find some bugs. My porting efforts are no exception — I've discovered that the value of ca_devsize of struct cfattach of OpenBSD's lm78_isa.c, which is used to malloc the structure that is about to hold some information specific to the device, is being set to a value that is about 8 bytes short of what it is supposed to be. Although it does not appear that anyone experienced crashes with this code (due to “luck” with alignment/padding?), this is definitely a bug, and as such I've just fixed it in OpenBSD, so it won't have a chance to get ported into FreeBSD. :)

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/isa/lm78_isa.c#rev1.2

CVSROOT:	/cvs
Module name:	src
Changes by:	cnst@	2007/07/01 15:48:57

Modified files:
	sys/dev/isa    : lm78_isa.c 

Log message:
fix potential crash due to wrong ca_devsize; whilst here, also fix iobase type; ok grange, kettenis

GSoC2007: Initial drivers part: Porting lm(4) from OpenBSD to FreeBSD

2007-06-29T21:34:53Z

Right now I'm busy porting the isa part of the lm(4) driver from OpenBSD to FreeBSD.

I have been stuck on trying to find the FreeBSD structures that are equivalent to OpenBSD's and NetBSD's struct isa_attach_args, which is used in the match and attach routines of isa drivers.

On NetBSD and OpenBSD, the following code can be used to initialise variables of type bus_space_tag_t and bus_space_handle_t, which are later used for accessing bus_space_write_1 and bus_space_read_1 functions:

int
lm_isa_match(struct device *parent, void *match, void *aux)
{
	bus_space_tag_t		iot;
	bus_space_handle_t	ioh;
	bus_addr_t		iobase;
	struct isa_attach_args *ia = aux;

	iot = ia->ia_iot;
	iobase = ia->ipa_io[0].base;

	if (bus_space_map(iot, iobase, 8, 0, &ioh)) {
		DPRINTF(("%s: can't map i/o space\n", __func__));
		return (0);
	}

	/* Probe for Winbond chips. */
	bus_space_write_1(iot, ioh, LMC_ADDR, WB_BANKSEL);
	...
}

Actual code from OpenBSD and NetBSD can be found at the locations below:
http://opengrok.creo.hu/openbsd/xref/src/sys/dev/isa/lm78_isa.c#lm_isa_match
http://opengrok.netbsd.org/source/xref/sys/dev/isa/lm_isa.c#lm_isa_match

As far the bus_space(9) functions themselves are concerned, it does appear that FreeBSD has all of these functions starting with FreeBSD 3.0, which were ported from NetBSD, according to the manual page. However, for some reason, I found very few drivers on FreeBSD that actually use bus_space_map() function, for example. For now, let's hope that they will work as soon as I figure out where to get iot and ioh. :)

…

Looking for some time at the drivers, I have found that the iot part can be simply initialised to I386_BUS_SPACE_IO, and as some drivers actually do with an XXX mark. :)

So this leaves me to figure out where to get iobase and ioh. Well, being stuck with this for a while, I decided to quickly hack this part as well, looking at what actual values are stored in these variables at the runtime of the lm(4) driver on OpenBSD. For this, I've created a simple patch for OpenBSD, which would print some variables:

Index: lm78_isa.c
===================================================================
RCS file: /cvs/src/sys/dev/isa/lm78_isa.c,v
retrieving revision 1.1
diff -u -d -p -4 -r1.1 lm78_isa.c
--- lm78_isa.c	2006/01/28 11:25:17	1.1
+++ lm78_isa.c	2007/06/29 21:09:04
@@ -68,13 +68,19 @@ lm_isa_match(struct device *parent, void
 
 	iot = ia->ia_iot;
 	iobase = ia->ipa_io[0].base;
 
+	printf("lm_isa_match: iot: %x; iobase: %x; ioh: %x;\n",
+	    iot, iobase, ioh);
+
 	if (bus_space_map(iot, iobase, 8, 0, &ioh)) {
 		DPRINTF(("%s: can't map i/o space\n", __func__));
 		return (0);
 	}
 
+	printf("lm_isa_match: iot: %x; iobase: %x; ioh: %x;\n",
+	    iot, iobase, ioh);
+
 	/* Probe for Winbond chips. */
 	bus_space_write_1(iot, ioh, LMC_ADDR, WB_BANKSEL);
 	banksel = bus_space_read_1(iot, ioh, LMC_DATA);
 	bus_space_write_1(iot, ioh, LMC_ADDR, WB_VENDID);
@@ -141,12 +147,18 @@ lm_isa_attach(struct device *parent, str
 
 	sc->sc_iot = ia->ia_iot;
         iobase = ia->ipa_io[0].base;
 
+	printf("lm_isa_attach: sc_iot: %x; iobase: %x; sc_ioh: %x;\n",
+	    sc->sc_iot, iobase, sc->sc_ioh);
+
 	if (bus_space_map(sc->sc_iot, iobase, 8, 0, &sc->sc_ioh)) {
 		printf(": can't map i/o space\n");
 		return;
 	}
+
+	printf("lm_isa_attach: sc_iot: %x; iobase: %x; sc_ioh: %x;\n",
+	    sc->sc_iot, iobase, sc->sc_ioh);
 
 	/* Bus-independant attachment */
 	sc->sc_lmsc.lm_writereg = lm_isa_writereg;
 	sc->sc_lmsc.lm_readreg = lm_isa_readreg;

And here are the relevant parts from the dmesg with this patch:

dale:constant {3104} dmesg | tail -n64 | grep -C lm
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
lm_isa_match: iot: 0; iobase: 290; ioh: 3bc;
lm_isa_match: iot: 0; iobase: 290; ioh: 290;
lm0 at isa0 port 0x290/8lm_isa_attach: sc_iot: 0; iobase: 290; sc_ioh: 290;
lm_isa_attach: sc_iot: 0; iobase: 290; sc_ioh: 290;
: W83627DHG
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
dale:constant {3105}

As one may notice, the 0x290 number is the address that is specified for lm0 device in the kernel configuration file, so we now know a few more things about how this stuff works. :)

Conclusion: for now, let's just initialise iot and iobase directly, call bus_space_map to get ioh, and the rest of the routine leave as is.

FreeBSD's packaging system

2007-06-10T00:34:43Z

I'm trying to install some xorg and kde packages on FreeBSD right now. Having almost exclusively used OpenBSD for the last few releases, I've come to take it for granted that the packaging system “just works”. :)

OpenBSD's packaging system is based on the one from FreeBSD; however, a few releases back OpenBSD's packaging system was extensively modified, so that right now updating existing packages, or installing a package or two from snapshots to an otherwise outdated package tree, happens without any conflicts for the majority of time.

In FreeBSD, however, every package still keeps a strict track of exact version numbers of all the other packages that are required to be installed in order for the package to function. As mentioned previously, on OpenBSD this is no longer the case — a region of several compatible versions of dependent packages can be specified by the package that is about to be installed.

Perhaps for Google's Summer of Code 2008 someone can come up with a way to port OpenBSD's improvements back into FreeBSD? :)