headers
Quentin Garnier | 1 Jan 2006 02:32

Device minor numbers conversion in COMPAT_NETBSD32

Hi folks,

A very unfortunate overlook (I can't blame anyone, though, it just had
to happen considering the hack that made it happen) introduced what is
now a rather hairy situation in amd64's COMPAT_NETBSD32.

It seems rather small, but I think it is hard to work around.  What
happens is that i386 has a very hacky way of defining minor device
numbers for disk devices.  In order to remain compatible with /dev
entries from the time i386's MAXPARTITIONS was 8, the 20th bit of the
minor number is used to code partitions 9-16 for each disk device.

I.e., on i386:

% ls -l /emul/netbsd32/dev/wd1[gi]
brw-r----- 0, 14     /emul/netbsd32/dev/wd1g
brw-r----- 0, 524296 /emul/netbsd32/dev/wd1i

Whereas, on amd64:

% ls -l /dev/wd1[gi]
brw-r----- 0, 22 /dev/wd1g
brw-r----- 0, 24 /dev/wd1i

I noticed that trying to boot an amd64 kernel over an i386 partition
which was on wd1g.  Booting an installed i386 partition with an amd64
kernel is something I'd really like to achieve, but this issue actually
makes it difficult.

So my first question is, do we want to allow this?  I.e., using a /dev
(Continue reading)

Permalink | Reply | 11 comments |
headers
D'Arcy J.M. Cain | 1 Jan 2006 15:58
Picon

Re: Cannot get priority range for scheduling policy 0

On Tue, 22 Nov 2005 06:57:41 -0500
"D'Arcy J.M. Cain" <darcy <at> NetBSD.org> wrote:
> Sorry for the cross post but I wasn't sure where this problem really
> was.  If you know, please feel free to drop the innapropriate one.
> 
> I just upgraded my system to -current as of yesterday and now when I
> run audacity I get this error.  I don't see it with any other program
> and audacity is the only one that uses the older wxGTK24 package.  The
> error follows a call to pthreads to get a policy number (which returns
> 0) and then fails getting a range for that policy.

I have since rebuilt the kernel, userland and packages and still get
this warning opping up for every file I open.  Does anyone have any
idea at least what the source of the error is?  Is it a change to a
library, the kernel or is it a problem with audacity?

--

-- 
D'Arcy J.M. Cain <darcy <at> NetBSD.org>
http://www.NetBSD.org/
Permalink | Reply | 0 comments |
headers
Ty Sarna | 2 Jan 2006 00:28

Re: yamt-uio_vmspace branch

> (assuming that the macro returns uio->uio_procp)
> 
> - if it's used to describe an address space, use uio->uio_vmspace instead.
> - otherwise, it's an abuse.  use the correct one instead.  eg. curproc.

It looks like it does b) already, at least in some places, for
__APPLE__. Though I wonder if that was all that was all that was wanted
why it wasn't a get_current_thread() macro instead of uio-based...

Love, can you shed any light on this, and wether simply defining the
macro to be curlwp->l_proc is sufficient?

Thanks
Permalink | Reply | 0 comments |
headers
swcdyys | 2 Jan 2006 07:16

how to run a application image in memory

Hi,
   When I use NetBSD as a embeded system, I have a LZMA-compressed application in flash, for save memory use, I
decompressed it to memory but not to RAMDISK, How can I run it from memory?
Permalink | Reply | 0 comments |
headers
swcdyys | 2 Jan 2006 07:16

how to run a application image in memory

Hi,
   When I use NetBSD as a embeded system, I have a LZMA-compressed application in flash, for save memory use, I
decompressed it to memory but not to RAMDISK, How can I run it from memory?
Permalink | Reply | 0 comments |
headers
Florian Stoehr | 2 Jan 2006 14:35
Picon

Missing splltp() for cobalt

Hi,

I tried to compile a cobalt 3.0 kernel with puc(4) enabled, which bails 
out in src/sys/dev/ic/lpc.c:244 - a call to spllpt().

Grepping showed that spllpt() is #defined to spltty() for most but not all 
ports:

sys/arch/acorn26/include/intr.h:#define spllpt()        raisespl(IPL_LPT)
sys/arch/algor/include/intr.h:#define   spllpt()        spltty()
sys/arch/alpha/include/intr.h:#define spllpt()          spltty()
sys/arch/amiga/include/intr.h:#define spllpt()  spl6()
sys/arch/amigappc/include/intr.h:#define spllpt()       spl6()
sys/arch/amigappc/include/intr.h:#define spllpt()       spltty()
sys/arch/arc/include/intr.h:#define spllpt()    spltty()                /* 
lpt driver */
sys/arch/arm/footbridge/footbridge_intr.h:#define spllpt()        spltty()
sys/arch/arm/include/arm32/psl.h:#define spllpt()       spltty()
sys/arch/atari/include/intr.h:#define spllpt()          spltty()
sys/arch/bebox/include/intr.h:#define spllpt()  spltty()
sys/arch/evbmips/include/intr.h:#define spllpt()        spltty()
sys/arch/evbsh5/include/intr.h:#define  spllpt() 
splsuperio()
sys/arch/hp700/include/intr.h:#define spllpt()  spltty()
sys/arch/hpcmips/include/intr.h:#define spllpt()        spltty()
sys/arch/ibmnws/include/intr.h:#define spllpt() spltty()
sys/arch/macppc/include/intr.h:#define spllpt() spltty()
sys/arch/mipsco/include/intr.h:#define spllpt() spltty()
sys/arch/mvmeppc/include/intr.h:#define spllpt()        spltty()
sys/arch/pmppc/include/intr.h:#define spllpt()  spltty()
(Continue reading)

Permalink | Reply | 2 comments |
headers
Elad Efrat | 2 Jan 2006 17:07
Picon

Re: how to run a application image in memory

swcdyys <at> mail.sc.cninfo.net wrote:
> Hi,
>    When I use NetBSD as a embeded system, I have a LZMA-compressed application in flash, for save memory use, I
decompressed it to memory but not to RAMDISK, How can I run it from memory?

not sure if this is what you're looking for but google for the grugq's
ulexec or "userland exec"; in one of recent phrack copies.

-e.

--

-- 
Elad Efrat
Permalink | Reply | 0 comments |
headers
zvrba | 2 Jan 2006 19:56
Picon
Favicon

lock-free data structures


Sorry if I'm a bit off-topic, but this is the only kernel-developers
mailing list that I'm subscribed to. The question is a practical one and
I believe that kernel developers can give the most informed answer.

Recently I've come across many papers describing the construction of
lock-free data structures using compare&exchange instructions. Such
implementations do not require explicit locks (mutexes) in an MP
environment. The advantages are more (no explicit locking needed) or
less (performance gains) obvious, so the question arises: why aren't
such data structures used more widely (in general and in the kernel
code?)

I know that Linux has adopted RCU, but again the example code for the
linked list traversal calls rcu_read_lock() / rcu_read_unlock() (thus,
not fulfilling the promise of lock-free code). Why didn't BSDs adopt RCU?
[ Please, I'm not trying to start a Linux vs. BSD war! This is a simple and
honest question related to my general inquiry. ]

Bottom line: what's the "catch" with lock-free data structures?

An immediate drawback is that not all architectures support the cmpxchg
instruction. What are others? Is the possible performance gain negligible
compared to the required effort of recoding a large volume of code?

Thanks for your answers.
Permalink | Reply | 16 comments |
headers
Ignatios Souvatzis | 2 Jan 2006 20:13
Picon

Re: lock-free data structures

hi,

zvrba <at> globalnet.hr wrote:

> Bottom line: what's the "catch" with lock-free data structures?
> 
> An immediate drawback is that not all architectures support the cmpxchg
> instruction.

Exactly.

	-is
Permalink | Reply | 8 comments |
headers
Alan Ritter | 2 Jan 2006 21:50
Picon

callout facility/old style timeout() for NetBSD NDIS

Hi, I ported the FreeBSD NDIS code to NetBSD as part of Google's
"Summer of Code", and now I'm trying to get it up to snuff to
hopefully include in NetBSD-current.

One problem that needs to be fixed has to do with the callout(9)
functions, and I noticed in the "History" section of the manpage that
you adapted it to NetBSD so I thought I'd write to solicit your
advice.

The problem I'm having is that Windows drivers use a "struct ktimer"
structure for timers which is emulated in FreeBSD using
timeout()/untimeout().  As NetBSD doesn't have these functions I
simply re-implemented everything using the newer callout facility. 
Following is the definition of the ktimer structure I use from
sys/compat/ndis/ntoskrnl_var.h

/*
  * We need to use the timeout()/untimeout() API for ktimers
 * since timers can be initialized, but not destroyed (so
  * malloc()ing our own callout structures would mean a leak,
  * since there'd be no way to free() them). This means we
  * need to use struct callout_handle, which is really just a
 * pointer. To make it easier to deal with, we use a union
 * to overlay the callout_handle over the k_timerlistentry.
 * The latter is a list_entry, which is two pointers, so
 * there's enough space available to hide a callout_handle
 * there.
 */

struct ktimer {
(Continue reading)

Permalink | Reply | 0 comments |

Gmane