Re: pserialize(9) vs. TAILQ

2014-11-22 Thread Dennis Ferguson
On 23 Nov, 2014, at 01:52 , Taylor R Campbell wrote: > [*] The x86 architecture happens to guarantee that if whoever inserted > the entry issues a store barrier (membar_producer) after initializing > e->key and before setting eq = e, this situation won't happen. But > that is not guaranteed on

Re: pserialize(9) vs. TAILQ

2014-11-22 Thread Dennis Ferguson
On 23 Nov, 2014, at 01:01 , Martin Husemann wrote: > On Sat, Nov 22, 2014 at 01:24:42PM +0800, Dennis Ferguson wrote: >> I'll guess one problem is in sparc/mutex.h, here: >> >>#define MUTEX_RECEIVE(mtx) /* nothing */ >>#define MUTEX_GIVE(mtx) /* nothing */ >

Re: Boot wedges

2014-11-22 Thread Rhialto
On Sun 23 Nov 2014 at 07:45:13 +1100, matthew green wrote: > is this in a manual somewhere? could you make it so if not? :) Speaking of the manual, it suggests that one can put in userconf=disable ethn* commands in boot.cnf. But when I tried it, it didn't seem to work (in a 6.1.5/amd64 system).

Re: Converting kernel printf() to aprint_*() or log()

2014-11-22 Thread Christos Zoulas
In article <18270.1416690...@splode.eterna.com.au>, matthew green wrote: > >Izaak writes: >> Hi, >> >> I am interested in working on the project to convert kernel printf to >> the appropriate aprint or log function: >> http://wiki.netbsd.org/projects/project/aprint/ >> >> There was a short disc

Re: Boot wedges

2014-11-22 Thread Michael van Elst
m...@eterna.com.au (matthew green) writes: >> I have added another option. The bootloader may pass a string >> that is interpreted as in 2. or 3. Like the other options, the >> data is passed in a global variable from MD to MI code. >> >> Previously defined variables are: >> >> boothowto

re: Converting kernel printf() to aprint_*() or log()

2014-11-22 Thread matthew green
Izaak writes: > Hi, > > I am interested in working on the project to convert kernel printf to > the appropriate aprint or log function: > http://wiki.netbsd.org/projects/project/aprint/ > > There was a short discussion about modifying log(9) in June: > http://mail-index.netbsd.org/tech-kern/2014

Re: Converting kernel printf() to aprint_*() or log()

2014-11-22 Thread Christos Zoulas
In article <20141118201629.GA30223@stishovite>, Izaak wrote: >On Tue, Nov 11, 2014 at 06:35:48PM -0500, Christos Zoulas wrote: >> On Nov 11, 11:11pm, mar...@duskware.de (Martin Husemann) wrote: >> -- Subject: Re: Converting kernel printf() to aprint_*() or log() >> >> | That sounds like a good p

Re: Converting kernel printf() to aprint_*() or log()

2014-11-22 Thread Christos Zoulas
In article , Jared McNeill wrote: >On Tue, 11 Nov 2014, Martin Husemann wrote: > >> - create a log_dev(device_t, const char *fmt, ...) function and use that >> in drivers instead of printf() when not in the driver's *_attach() >> function (or functions only called from that); use log(9) where

re: Boot wedges

2014-11-22 Thread matthew green
> I have added another option. The bootloader may pass a string > that is interpreted as in 2. or 3. Like the other options, the > data is passed in a global variable from MD to MI code. > > Previously defined variables are: > > boothowto - boot flags > booted_device - the boot d

Re: pserialize(9) vs. TAILQ

2014-11-22 Thread Taylor R Campbell
Date: Sat, 22 Nov 2014 11:49:34 +0900 From: Masao Uebayashi You are right that "key" has to be volatile. But otherwise, you are making things too complex, or too generic, which is not what I'm expecting as a TAILQ-specialized-for-pserialize(9). No, volatile is unrelated to multip

Re: pserialize(9) vs. TAILQ

2014-11-22 Thread Martin Husemann
On Sat, Nov 22, 2014 at 01:24:42PM +0800, Dennis Ferguson wrote: > I'll guess one problem is in sparc/mutex.h, here: > > #define MUTEX_RECEIVE(mtx) /* nothing */ > #define MUTEX_GIVE(mtx) /* nothing */ > > This works with TSO, but with RMO they need to somehow

Boot wedges

2014-11-22 Thread Michael van Elst
So far, the netbsd kernel supported several methods to determine a root disk. 1. A literal device denoted by major/minor number in the kernel configuration. 2. A literal device name in the kernel configuration. The kernel accepts either a driver+unit string (e.g. "sd0") or the string "we