| bash.org.ru |
[Вт, 2008-05-20T21:58] |
Дело происходит в University of Ottawa.
Суббота, 2008-05-17, около 11:25 северо-американского восточного времени.
Подхожу к зданию SITE. Захожу в аудиторию G. В аудитории полно народу, включая phk и matthieu, сидящие в одном ряду друг напротив друга (позже оказалось, что места были выбраны из корыстных соображений, дабы получить доступ к розеткам, которые были в ограниченном доступе). Быстро пытаюсь найти кого-нибудь с расписанием. Смотрю — на последнем ряду как раз сидит тов. Тарасов. Подхожу, вглядываюсь в его монитор, спрашивая, чей Talk здесь сейчас будет, одновременно с этим замечая открытый браузер с bash.org.ru. “Твой!”, — недоумённо отвечает тов. Тарасов…
( Read more... ) |
|
|
| GSoC2007.cnst-sensors.2007-09-13.patch |
[Чт, 2007-09-13T18:50] |
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:
( Read more... ) |
|
|
| 12-year-old bug in FreeBSD's kern_sysctl.c |
[Пн, 2007-09-03T15:22] |
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. |
|
|
| Committing things upstream |
[Сб, 2007-08-18T13:03] |
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. |
|
|
| /sys/kern/kern_sysctl.c in FreeBSD |
[Ср, 2007-07-25T17:32] |
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! :)
( Read more... ) |
|
|
| Koders.com now searches symon, too! |
[Чт, 2007-07-12T15:17] |
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. ;)
( Read more... ) |
|
|
| (без темы) |
[Пн, 2007-07-09T18:46] |
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 :(
( Read more... ) |
|
|
| Porting means you get to find bugs in original implementation! |
[Вс, 2007-07-01T18:18] |
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. :)
( Read more... ) |
|
|
| GSoC2007: Initial drivers part: Porting lm(4) from OpenBSD to FreeBSD |
[Пт, 2007-06-29T13:04] |
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. :)
( Read more... ) |
|
|
| FreeBSD's packaging system |
[Сб, 2007-06-09T20:03] |
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? :) |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
cnst