Re: Mdns

Any feedback is welcome.

Re: tcpbe...@libevent

Sorry, wrong diff forgot the bogus SO_RDOMAIN define (old base). I've just remembered I've changed the -r option from miliseconds to seconds I'll fix that and send another patch with miliseconds, the rest should be ok. Index: tcpbench.c

Mdns

Hi there, I've released a working version of mdnsd, an ISC licensed implementation of MDNS/DNS-SD for OpenBSD, a replacement for avahi/bonjour (http://github.com/haesbaert/mdnsd). I've started this cause I hate having a MDNS/DNS-SD implementation with 60k+ lines (avahi). The querier is almost fu

tcpbe...@libevent

Hi, I've rewritten tcpbench to use libevent as suggested before. Code got a little smaller but I couldn't notice any performance changes (tested up to 1500 fds). There is still only one O(n) operation each second: the stats accounting. Turned some variables into globals for the sake of clarity, as

Re: ARM linker script

On Wed, Oct 13, 2010 at 08:29:35PM -0500, Dale Rahn wrote: > On Thu, Oct 14, 2010 at 01:50:36AM +0200, Tobias Ulmer wrote: > > I'm currently loading the kernel at a fixed start address using u-boot. > > There's no relocation going on. > > Accessing anything in the data segment leads to crashes due

Re: ARM linker script

On Thu, Oct 14, 2010 at 01:50:36AM +0200, Tobias Ulmer wrote: > I'm currently loading the kernel at a fixed start address using u-boot. > There's no relocation going on. > Accessing anything in the data segment leads to crashes due to file- and > address offsets desyncing. > > The patch below fixe

Re: important new unit

May I also lament the lack of donkeypower for those days when the supermarket has just plain run out of horses. On Wed, Oct 13, 2010 at 08:02:47PM -0400, Ted Unangst wrote: > Let's say you have a football field in need of a trimming, but the lawn > mowers are all broken, but you have an oxen sto

yield in long kernel loops

So it's not a good idea to perform long lasting operations in the kernel. The scheduler doesn't deal well with it and nobody else gets to run. One of those long loops is loading a large table into pf. If you're lucky, you'll run out of memory and pool will finally sleep. I stuck a couple yiel

important new unit

Let's say you have a football field in need of a trimming, but the lawn mowers are all broken, but you have an oxen store nearby. Oh, and the big match is in an hour. How many oxen do you need? Normally, you'd use units, but... You have: m2/hr You want: ox unknown unit 'ox' Easy fix. Working

ARM linker script

I'm currently loading the kernel at a fixed start address using u-boot. There's no relocation going on. Accessing anything in the data segment leads to crashes due to file- and address offsets desyncing. The patch below fixes this issue and, as a bonus, syncs the code with the comment. Possibly af

Ingles Online en vivo con InglesPlus.com

Si no puede ver este Newsletter correctamente, o desea ver la version HTML completa presione en el SIGUIENTE LINK http://www.editorialpoulbert.com.ar/Newsletter/2010/09_septiembre/inglesplus/inglesplus.html - My E

Re: remove a bunch of custom pci bridge devices from the install media

On Thu, Oct 14, 2010 at 12:04 AM, Brad wrote: > On Wednesday 13 October 2010 14:10:55 Daniel B. wrote: >> On Wed, 13 Oct 2010, Brad wrote: >> > I don't see why you didn't also make the same changes to RAMDISK_CD to >> > keep all of the i386 RAMDISK media consistent, especially if these >> > driver

Re: remove a bunch of custom pci bridge devices from the install media

On Wednesday 13 October 2010 14:10:55 Daniel B. wrote: > On Wed, 13 Oct 2010, Brad wrote: > > I don't see why you didn't also make the same changes to RAMDISK_CD to > > keep all of the i386 RAMDISK media consistent, especially if these > > drivers are not necessary for the RAMDISK to operate proper

Re: remove a bunch of custom pci bridge devices from the install media

On Wed, 13 Oct 2010, Brad wrote: > I don't see why you didn't also make the same changes to RAMDISK_CD to keep > all of the i386 RAMDISK media consistent, especially if these drivers are not > necessary for the RAMDISK to operate properly. http://marc.info/?l=openbsd-cvs&m=128699934012824&w=2

Re: remove a bunch of custom pci bridge devices from the install media

On Wednesday 13 October 2010 14:25:45 Mike Belopuhov wrote: > each of them wastes about 1k of precious disk space, > none of them serves any purpose as what they do in > the case of SMALL_KERNEL is call pcibattach. > pcib(4) can do it on its own. > > having a cheap timecounter source is irrelevant

Re: remove a bunch of custom pci bridge devices from the install media

> Date: Wed, 13 Oct 2010 20:25:45 +0200 > From: Mike Belopuhov > > each of them wastes about 1k of precious disk space, > none of them serves any purpose as what they do in > the case of SMALL_KERNEL is call pcibattach. > pcib(4) can do it on its own. > > having a cheap timecounter source is irr

Postanite član kluba - plaćajte manje

Top Shop ; Sve iz Kluba 5* Neverovatna sniE>enja Kluba 5* samo na Top Shop-u! Klub 5* Kako do super pogodnosti? Obezbedite sebi posebne pogodnosti i kupujte pametno - postane D lan Kluba 5*. U okobru uz svaku porudE>binu Kluba 5* POKLON Wash Bag! Prednosti za D lanove Kluba 5*: NiE>e cene pr

remove a bunch of custom pci bridge devices from the install media

each of them wastes about 1k of precious disk space, none of them serves any purpose as what they do in the case of SMALL_KERNEL is call pcibattach. pcib(4) can do it on its own. having a cheap timecounter source is irrelevant in the install phase. i've tested it with glxpcib and ichpcib, but oth

ld.so search order

Currently our runtime linker must locate a shared library via hits, or directory search operations prior to identifying the shared library is already loaded. This differs from Linux, FreeBSD and Solaris at least, where loaded objects are checked for matches first. This difference prevents a usef

Re: amd64 segment cleanup

On Sat, Oct 09, 2010 at 01:11:05PM -0700, Philip Guenther wrote: > The diff below is the first step in a clean up of the amd64 low-level > segment bits. This step is to switch user-space to using code and data > segments in the global descriptor table (GDT) instead of the local > descriptor tab

switch remaining libdes users to libcrypto

This does not include regress, but should otherwise switch all users of libdes in src to libcrypto. Survives a build/release on amd64, tests to make sure this doesn't break anything at runtime welcome. Index: distrib/miniroot/makeconf.awk ==

Gerenciamiento de Emprendimientos Inmobiliarios, Obras y Proyectos

CURSO INTENSIVO 2 dmas en Buenos Aires, Argentina (Lunes 25 y martes 26 de octubre 2010, de 9 a 18 hs.) Gerenciamiento de emprendimientos inmobiliarios, obras y proyectos Herramientas de project management para afrontar la incertidumbre Este es un curso

Re: amd64 segment cleanup

> Date: Sat, 9 Oct 2010 13:11:05 -0700 > From: Philip Guenther > > The diff below is the first step in a clean up of the amd64 low-level > segment bits. This step is to switch user-space to using code and data > segments in the global descriptor table (GDT) instead of the local > descriptor t