Re: Changing the return value of xxx_attach() from void to int.

On Fri, Jun 24, 2016 at 2:42 PM, Michael van Elst <mlel...@serpens.de> wrote: > uebay...@gmail.com (Masao Uebayashi) writes: > >>Ideally xxxattach() becomes re-startable and can return EAGAIN so >>autoconf(9) will call it when things are ready. > > Why would a driver

Re: Introduce curlwp_bind and curlwp_unbind for psref(9)

On Tue, Jun 28, 2016 at 10:08 AM, Ryota Ozaki wrote: > On Sat, Jun 25, 2016 at 11:56 AM, matthew green wrote: >>> > Since we already use preempt_disable() to force an lwp to stick to a cpu, >>> > doesn't that solve the problem? If need be, we can enforce

Re: Changing the return value of xxx_attach() from void to int.

On Fri, Jun 24, 2016 at 2:02 AM, Michael wrote: > Hello, > > On Thu, 23 Jun 2016 16:13:53 + > Taylor R Campbell wrote: > >>Date: Thu, 23 Jun 2016 19:40:14 +0900 >>From: Masanobu SAITOH >> >> As you

Re: Introduce curlwp_bind and curlwp_unbind for psref(9)

On Fri, Jun 17, 2016 at 12:57 PM, Matt Thomas wrote: > >> On Jun 13, 2016, at 5:53 PM, Ryota Ozaki wrote: >> >> On Mon, Jun 13, 2016 at 11:21 PM, Taylor R Campbell >> wrote: >>> Date: Mon, 13 Jun 2016 14:00:16

Re: uvm vm_physseg trimming

avail_start/avail_end are used to keep track of the range used for "managed pages" - PAGE_SIZE'ed pages that are added to free list and allocated from there. Managed pages are initially added after kernel reserves its internal, bootstrap memory region (.text, .data, ...). In some cases kernel

Re: Problem with syscall_disestablish() - PR kern/50430

On Thu, Nov 19, 2015 at 1:43 PM, Paul Goyette <p...@vps1.whooppee.com> wrote: > On Thu, 19 Nov 2015, Masao Uebayashi wrote: > >> On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette <p...@vps1.whooppee.com> >> wrote: >>> >>> Based on earlier comments,

Re: Problem with syscall_disestablish() - PR kern/50430

On Thu, Nov 19, 2015 at 10:30 PM, Eric Haszlakiewicz wrote: > On November 19, 2015 4:28:46 AM EST, Paul Goyette > wrote: >>And if there's anyone who really understands HOW the initial syscall >>gets interrupted when the signal is being delivered (and

Re: Problem with syscall_disestablish() - PR kern/50430

On Wed, Nov 18, 2015 at 3:18 PM, matthew green wrote: >> >>> there's a fairly significant problem with this implementation. >> >>> >> >>> you're only catching callers who use end up going through sy_call() >> >>> and that's not the majority. mostly they're called directly

Re: kern_sig.c

On Sat, Nov 21, 2015 at 8:21 PM, Masao Uebayashi <uebay...@gmail.com> wrote: > On Sat, Nov 21, 2015 at 8:13 PM, Masao Uebayashi <uebay...@gmail.com> wrote: >> I'm too young to understand how signal works in kernel. But I guess >> I'm not alone. >> >> I thin

Re: kern_sig.c

On Sat, Nov 21, 2015 at 8:13 PM, Masao Uebayashi <uebay...@gmail.com> wrote: > I'm too young to understand how signal works in kernel. But I guess > I'm not alone. > > I think that renaming things a bit would help people to understand the code. > > * > -

kern_sig.c

I'm too young to understand how signal works in kernel. But I guess I'm not alone. I think that renaming things a bit would help people to understand the code. * - sendsig() -> netbsd_sendsig() - trapsignal() -> netbsd_trapsignal() These are native emul functions of e_sendsig and e_trapsignal

Re: Problem with syscall_disestablish() - PR kern/50430

On Wed, Nov 18, 2015 at 11:07 AM, Paul Goyette wrote: > Based on earlier comments, I've come up with a much-less-intrusive > set of changes. This time around, there are no bit masks and no new > members in any system structures. (I'm pretty sure we won't even > need a

Re: POSIX.1 semaphores vs message queues

On Sat, Nov 14, 2015 at 2:49 AM, Christos Zoulas <chris...@astron.com> wrote: > In article > <cadbf7eddkdnzjfnpdsdjk+rcnbfwf8xxomuvg+vp9fupej8...@mail.gmail.com>, > Masao Uebayashi <uebay...@gmail.com> wrote: >> >>I have tried to explain the need of

Re: POSIX.1 semaphores vs message queues

On Mon, Nov 9, 2015 at 7:13 PM, John Nemeth <jnem...@cue.bc.ca> wrote: > On Nov 9, 11:15am, Masao Uebayashi wrote: > } On Mon, Nov 9, 2015 at 9:21 AM, Joerg Sonnenberger > } <jo...@britannica.bec.de> wrote: > } > On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyet

Re: POSIX.1 semaphores vs message queues

On Fri, Nov 13, 2015 at 8:05 PM, John Nemeth <jnem...@cue.bc.ca> wrote: > On Nov 13, 6:34pm, Masao Uebayashi wrote: > } On Mon, Nov 9, 2015 at 7:13 PM, John Nemeth <jnem...@cue.bc.ca> wrote: > } > On Nov 9, 11:15am, Masao Uebayashi wrote: > } > } On Mon, Nov 9, 2015

Re: POSIX.1 semaphores vs message queues

On Sun, Nov 8, 2015 at 7:52 AM, Joerg Sonnenberger wrote: > On Sun, Nov 08, 2015 at 06:35:36AM +0800, Paul Goyette wrote: >> On Sat, 7 Nov 2015, Joerg Sonnenberger wrote: >> >> >On Sat, Nov 07, 2015 at 10:55:49AM +0800, Paul Goyette wrote: >> >>I'd like to understand the

Re: kernel libraries and dead code in MODULAR kernels

(Coming back to the original post.) On Mon, Aug 31, 2015 at 10:55 AM, Dennis Ferguson wrote: > I've been compiling the same kernel configuration with and without > options MODULAR and noticed that the MODULAR kernels have a not > inconsiderable amount of code that is

Re: Inter-driver #if dependencies

On Mon, May 18, 2015 at 7:40 AM, Paul Goyette p...@vps1.whooppee.com wrote: My crusade for modularity has arrived at the pcppi(4) driver, and I've discovered that there are a number of places in the code where a #if is used to determine whether or not some _other_ driver is available to provide

Re: config_init_component(), ioconf, and pseudo-devices

On Thu, Apr 16, 2015 at 5:34 PM, Paul Goyette p...@vps1.whooppee.com wrote: I'm working on turning swwdog (for now, eventually others) into a kernel module, and I'm running into some difficulty with the autoconfig stuff. I've got an IOCONF=swwdog.ioconf in my Makefile, and swwdog.ioconf

Re: tracking P-V for unmanaged device pages

On Thu, Apr 9, 2015 at 11:46 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: In my pmap_pv API, there's no need to change pmap_enter. All you need to do is to call pmap_pv_track on driver attach to mark the pages as device pages. Then pmap can do the bookkeeping

Re: tracking P-V for unmanaged device pages

- struct vm_physseg is MI representation of a continuous physical address region. It is currently allocated only for main memories, but apertures should have one. - struct vm_page is MI representation of memory pages that have backing stores; IOW, a state between memory page and its backing

Re: pserialize hw interrupt

On Tue, Dec 9, 2014 at 5:41 PM, Ryota Ozaki ozak...@netbsd.org wrote: In the case of softint-ed interrupts on, I think we can safely remove the indirection. OTOH, in the case of off, I'm not sure we can do the same thing. As far as you don't break other virtio(4) drivers than vioif(4)...

Re: pserialize hw interrupt

I see that vioif(4) schedules another softint from within vioif_rx_vq_done(), that would latency a bit longer. +#define VIRTIO_F_PCI_INTR_SOFTINT (2 0) Usually (1 1).

Re: driver concurrency

On Tue, Dec 2, 2014 at 5:32 AM, Thor Lancelot Simon t...@panix.com wrote: Try it! It's quite a mess, particularly around target and bus attach/detach. scsipi and wscons are the worst in that respect. (Who wants to be a hero?)

Re: Critical section

With a few changes which I've just committed, now the tree is consistent: - kpreempt_{disable,enable}(): I don't want to enter scheduler! - KPREEMPT_{DISABLE,ENABLE}(): I've entered scheduler!

Re: Critical section

On Fri, Nov 28, 2014 at 12:20 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Wed, 26 Nov 2014 16:41:01 +0900 From: Masao Uebayashi uebay...@gmail.com The problem of kpreempt_*() API is that its meaning is overriden by kernel internal (scheduler, sync

Re: Critical section

On Fri, Nov 28, 2014 at 8:47 AM, Mindaugas Rasiukevicius rm...@netbsd.org wrote: Masao Uebayashi uebay...@gmail.com wrote: The problem of kpreempt_*() API is that its meaning is overriden by kernel internal (scheduler, sync primitives, ...). This change separates the internal use (scheduler

Re: Critical section

On Fri, Nov 28, 2014 at 12:40 AM, Masao Uebayashi uebay...@gmail.com wrote: It turned out that prohibiting nesting was too strict, and just plain wrong. CPU can enter critical section C1, interrupted, and enter C2, etc. The cprng_fast.c assertion is OK. Sorry for confusion. Still thinking

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

I overlooked you've back out the struct callout * dynamic allocation part. Can you make it use kmem as I showed?

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Wed, Nov 26, 2014 at 5:53 PM, Ryota Ozaki ozak...@netbsd.org wrote: On Wed, Nov 26, 2014 at 5:09 PM, Masao Uebayashi uebay...@gmail.com wrote: I overlooked you've back out the struct callout * dynamic allocation part. Can you make it use kmem as I showed? Hmm, I'll do so, although I don't

Re: Critical section

Critical section must stop soft interrupt which may block sleep (using the preempted lwp). Thus critical sections must be at least IPL_SOFTSERIAL. On Wed, Nov 26, 2014 at 4:41 PM, Masao Uebayashi uebay...@gmail.com wrote: The problem of kpreempt_*() API is that its meaning is overriden

Re: Critical section

On Thu, Nov 27, 2014 at 1:38 AM, Matt Thomas m...@3am-software.com wrote: That is not true. If the softint thread sleeps, control is returned back to the preempted lwp. You're right. I keep forgetting how softint works. Sigh. - Generic soft interrupt is implemented as kthread, and is not

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Tue, Nov 25, 2014 at 7:18 PM, Ryota Ozaki ozak...@netbsd.org wrote: Hmm, if_flags. http://mail-index.netbsd.org/tech-net/2009/01/27/msg000985.html Do we have to care about kvm(3) users (i.e., netstat) as well as the callout_t issue? For new flags, you can reuse if__pad1. I don't

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

I think I can help sysctl'ification, but let's check in this callout thing first.

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Wed, Nov 26, 2014 at 12:29 AM, Ryota Ozaki ozak...@netbsd.org wrote: Yes, we can extend if_flags to int by unifying with if__pad1, and it works for the kernel and for old userland programs on little endian machines. However, it doesn't work for old userland programs on big endian machines,

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Wed, Nov 26, 2014 at 1:31 AM, Ryota Ozaki ozak...@netbsd.org wrote: I'd change if__pad1 to if_flags2 and define IFF2_SLOWTIMO_MPSAFE etc. Hmm, I think it's a last resort. I don't want to do something like (ifp-if_flags IFF_XXX) (ifp-if_flags2 IFF_XXX2) if possible. I'm thinking more to

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Wed, Nov 26, 2014 at 1:02 PM, Ryota Ozaki ozak...@netbsd.org wrote: Here is a latest patch: http://www.netbsd.org/~ozaki-r/watchdog-callout-per-if.diff OK from me. So my remaining concern is whether we can embed callout_t with _KERNEL which I proposed earlier. If the answer is no, the

Critical section

The problem of kpreempt_*() API is that its meaning is overriden by kernel internal (scheduler, sync primitives, ...). This change separates the internal use (scheduler disables preeemption) and others (kernel subsystem code executes critical section). Detect sleep from within critical section

Re: pserialize(9) vs. TAILQ

On Tue, Nov 25, 2014 at 9:38 AM, Mindaugas Rasiukevicius rm...@netbsd.org wrote: I would rather extend atomic_ops(3) API to have functions which ensure a particular memory barrier or a function which takes the constraint as an extra argument, like in C11 API. Speaking of which, it might be

Re: pserialize(9) vs. TAILQ

On Sun, Nov 23, 2014 at 5:00 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: I was happy with no barrier in the reader when I thought providing support for the DEC Alpha architecture's unique cache quirk wasn't necessary. When it turned out support for the Alpha was necessary the

Re: pserialize(9) vs. TAILQ

21:44:11 +0900 From: Masao Uebayashi uebay...@gmail.com - TAILQ_REMOVE() will work (except on Alpha) - TAILQ_INSERT_*() will not (on Alpha and some others) - TAILQ_INSERT_*() need membar_producer() - TAILQ_FOREACH() needs membar_consumer() - TAILQ_REMOVE works

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Mon, Nov 24, 2014 at 11:16 PM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Mon, 24 Nov 2014 15:26:21 +0900 From: Masao Uebayashi uebay...@gmail.com (I'm trying, but I can't follow up all mails soon, because I need more than x2 energy time to write

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Tue, Nov 25, 2014 at 12:48 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Tue, 25 Nov 2014 00:42:58 +0900 From: Masao Uebayashi uebay...@gmail.com On Mon, Nov 24, 2014 at 11:16 PM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote

Re: pserialize(9) vs. TAILQ

On Tue, Nov 25, 2014 at 1:44 AM, Eduardo Horvath e...@netbsd.org wrote: Yes, the existing code assumes TSO. A while back I was looking in to fixing that. I enhanced membar_ops with proper memory barriers and then was looking at the mutex code. Unfortunately, I didn't get very far. It

Re: mutex(9) on sparc64 RMO [was Re: pserialize(9) vs. TAILQ]

On Tue, Nov 25, 2014 at 2:19 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Mon, 24 Nov 2014 16:44:41 + (UTC) From: Eduardo Horvath e...@netbsd.org I enhanced membar_ops with proper memory barriers and then was looking at the mutex code.

Re: pserialize(9) vs. TAILQ

On Tue, Nov 25, 2014 at 3:55 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 25 Nov, 2014, at 00:56 , Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: My confusion came from that I thought memory ordering of load is more flexible in general. I also didn't quite

Re: pserialize(9) vs. TAILQ

On Sat, Nov 22, 2014 at 2:24 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: I'll guess one problem is in sparc/mutex.h, here: #define MUTEX_RECEIVE(mtx) /* nothing */ #define MUTEX_GIVE(mtx) /* nothing */ I think that these macros should be

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

http://marc.info/?t=14167055271r=1w=2 Following the ideas raised in that thread: - Allocate callout_t dynamically. struct ifnet only has a pointer to struct callout, which will not be read by netstat(1) anyway. - Prefer the name slowtimo to watchdog, because those callbacks do a little

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

(I'm trying, but I can't follow up all mails soon, because I need more than x2 energy time to write English than you.) On Mon, Nov 24, 2014 at 12:12 PM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Mon, 24 Nov 2014 11:23:28 +0900 From: Masao Uebayashi uebay

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Mon, Nov 24, 2014 at 3:26 PM, Masao Uebayashi uebay...@gmail.com wrote: netstat(1) needs to know struct type information (by building if.c) to s/ (by building if.c) / (by including if.h) /

Re: pserialize(9) vs. TAILQ

On Thu, Nov 20, 2014 at 4:45 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 20 Nov, 2014, at 11:07 , Masao Uebayashi uebay...@gmail.com wrote: On Wed, Nov 19, 2014 at 2:49 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: That's very true, but the code is only correct

Re: pserialize(9) vs. TAILQ

On Sat, Nov 22, 2014 at 1:22 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Sat, 22 Nov 2014 01:03:58 +0900 From: Masao Uebayashi uebay...@gmail.com The problem of TAILQ_INSERT_*() macros with respect to pserialize(9) is that, as you are pointing out

Re: pserialize(9) vs. TAILQ

On Sat, Nov 22, 2014 at 1:31 AM, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 22, 2014 at 1:22 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Sat, 22 Nov 2014 01:03:58 +0900 From: Masao Uebayashi uebay...@gmail.com The problem of TAILQ_INSERT_

Re: pserialize(9) vs. TAILQ

On Sat, Nov 22, 2014 at 5:38 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Sat, 22 Nov 2014 01:31:48 +0900 From: Masao Uebayashi uebay...@gmail.com On Sat, Nov 22, 2014 at 1:22 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote

Re: pserialize(9) vs. TAILQ

On Sat, Nov 22, 2014 at 11:49 AM, Masao Uebayashi uebay...@gmail.com wrote: It is users' choice whether using fast-changing values as a key or not, but if you decide to change values visible by pserialize(9) readers, you'll end up with ensuring memory order. It is your choice, but beyond

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Thu, Nov 20, 2014 at 6:16 PM, Ryota Ozaki ozak...@netbsd.org wrote: BTW, moving #include sys/callout.h out of #ifdef _KERNEL doesn't work because struct callout of callout.h conflicts with that of external/bsd/am-utils. (Fixing this conflict is an option though...) Thanks, ozaki-r

Re: pserialize(9) vs. TAILQ

On Wed, Nov 19, 2014 at 10:00 PM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Wed, 19 Nov 2014 17:11:18 +0800 From: Dennis Ferguson dennis.c.fergu...@gmail.com On 19 Nov, 2014, at 01:53 , Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: The

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Thu, Nov 20, 2014 at 11:38 AM, Ryota Ozaki ozak...@netbsd.org wrote: Actually FreeBSD seems to have a callout for each interface. Even more they killed the common if_watchdog facility and each driver has its own. What happens if many (e.g. 1,000) virtual ifs are present? Anyway here is a

Re: pserialize(9) vs. TAILQ

On Wed, Nov 19, 2014 at 2:49 PM, Dennis Ferguson dennis.c.fergu...@gmail.com wrote: That's very true, but the code is only correct if the writes occur in the order the C code has them written (i.e. tqe_next in the new element is written before writing the tqe_next of the existing list element

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

Looks good to me. But you should test before commit. :)

pserialize(9) vs. TAILQ

I thought I kind of understood how pserialize(9) works, but the manual confused me: mutex_enter(writer_psz_lock); /* * Perform the updates (e.g. remove data items from a list). */ ... pserialize_perform(object-psz);

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Mon, Nov 17, 2014 at 7:03 PM, Ryota Ozaki ozak...@netbsd.org wrote: - http://www.netbsd.org/~ozaki-r/psz-ifnet.diff IFNET_RENTER(); IFNET_FOREACH() { if-if_watchdog(); } IFNET_REXIT(); This is not safe; if_watchdog() may resend packets, too slow operation to do in critical section.

Re: pserialize(9) vs. TAILQ

On Wed, Nov 19, 2014 at 10:15 AM, Masao Uebayashi uebay...@gmail.com wrote: On Wed, Nov 19, 2014 at 2:53 AM, Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: The one tricky detail is that after a reader has fetched the tqe_next pointer, it must issue a membar_consumer before

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Wed, Nov 19, 2014 at 11:24 AM, Ryota Ozaki ozak...@netbsd.org wrote: Weird :-/ I don't think so. For fast paths to access data really fast, slow paths take a little way around (pre-allocation, etc). This is a fair trade-off. If you can achieve such a goal (e.g. lockless access of list)

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Mon, Nov 17, 2014 at 7:03 PM, Ryota Ozaki ozak...@netbsd.org wrote: - http://www.netbsd.org/~ozaki-r/psz-ifnet.diff There are many copyout()'s while IFNET_LOCK() is taken. I'd agree with dyoung@, I think restructure should be done first...

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Mon, Nov 17, 2014 at 7:03 PM, Ryota Ozaki ozak...@netbsd.org wrote: - http://www.netbsd.org/~ozaki-r/ifget-ifput.diff Is it possible to have another dying flag in struct refcount, so that ifput() can atomically set it without taking a lock, then later call a g/c call?

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

On Tue, Nov 18, 2014 at 11:24 AM, Ryota Ozaki ozak...@netbsd.org wrote: First I'm not against restructuring, though I hoped minimum restructuring on non-performance-sensitive paths. My understanding is that, non-performance-sensitive paths (e.g. ioctl()'s) also touches performance-sensitive

link-set

This is what I've learned about link-set. TL;DR - link-set is fine except already unused sections are exposed after final link * - link-set is a set of macros __link_set_*` defined in sys/cdefs.h (actually sys/cdefs_*.h). - link-set provides format-neutral way to generate linker sections. -

__attribute__((constructor)) in kernel

What I've learned about it. TL;DR - .not really useful for kernel * - It generates a .ctors (or .init_array on arm or something) section - GCC has __attribute__((constructor(n))) where n is priority, and the section entries are sorted in ascending order, which is a handy syntax - But not

Re: link-set

On Fri, Nov 14, 2014 at 3:10 AM, Kamil Rytarowski n...@gmx.com wrote: Maybe irrelevant here, but with you work could we consider having room for possible implementation of FDT [1]? FDT (Flattened Device Tree) is a binary configuration file for kernel, heavily used in embedded Linux and

Re: kernel constructor

On Wed, Nov 12, 2014 at 2:53 AM, Taylor R Campbell campb...@mumble.net wrote: Date: Tue, 11 Nov 2014 17:42:51 + From: Antti Kantee po...@iki.fi 2: init_main ordering I think that code reading is an absolute requirement there, i.e. we should be able to know offline

Re: kernel constructor

(snip) How about spending your energy to investigate real dependencies, for example: http://nxr.netbsd.org/xref/src/sys/kern/init_main.c#559 Does pax depend on veriexec? Does ipsec depend on pax?

Re: kernel constructor

On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski n...@gmx.com wrote: From David Holland Please don't do that. Nothing good can come of it - you are asking for a thousand weird problems where undisclosed ordering dependencies silently manifest as strange bugs. Everyone is aware of that. Code

Re: MI linker script

I've found that linker script can have multiple SECTIONS commands. This may be able to save the intermediate ld -r by concatenate MI + MD scripts. Let me try...

Re: kernel constructor

On Mon, Nov 10, 2014 at 5:25 PM, Martin Husemann mar...@duskware.de wrote: On Sun, Nov 09, 2014 at 05:46:21PM -0800, Matt Thomas wrote: No more link sets please. I agree. I agreed one week ago. But now I have MI linker script that merges link_set_* into .rodata, I can live with link-set. :)

Re: kernel constructor

On Mon, Nov 10, 2014 at 7:46 PM, Justin Cormack jus...@specialbusservice.com wrote: On Nov 10, 2014 10:02 AM, Masao Uebayashi uebay...@gmail.com wrote: __attribute__((constructor(n))), where n being priority, can do ordering (hint from pooka@). Question is, how to provide __CTOR_LIST__

Re: kernel constructor

On Tue, Nov 11, 2014 at 11:48 AM, Thor Lancelot Simon t...@panix.com wrote: On Sun, Nov 09, 2014 at 04:16:13PM +0900, Masao Uebayashi wrote: Ideally the long hardcoded sequence of init functions in init_main:main() is converted to a single vector whose order is resolved by modular dependency

.eh_frame

Do I understand this correctly? o .eh_frame is GNU extension debug info to unwind stack [1] o .eh_frame is generated by GCC/LLVM [2] o Some code under src/sys/ reference it, but not finished hooked to any kernel functionality (ddb(4)?) o .eh_frame in kernel is not used yet, and safely removed

Re: .eh_frame

On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote: o .eh_frame is GNU extension debug info to unwind stack [1] No. Ian Lance Taylor said that it is similar to DWARF .debug_frame, but different

Re: .eh_frame

On Mon, Nov 10, 2014 at 4:02 AM, Andrew Cagney andrew.cag...@gmail.com wrote: You might find this useful: http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-October/005546.html Several notes: - while eh_frame is meant to be the minimum information needed to unwind function calls, the desire

Re: .eh_frame

On Mon, Nov 10, 2014 at 2:12 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Nov 10, 2014 at 01:40:59AM +0900, Masao Uebayashi wrote: On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi

Re: MI linker script

On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: depending on ld -r to work properly I know none of you trust me, but you don't trust ld -r? It is not me but others (mainly dsl@) who repeatedly brought up usefulness of ld -r. I didn't know how to use it, whether it

Re: MI linker script

Something like this: https://mail-index.netbsd.org/tech-kern/2012/05/28/msg013235.html In short: making kernel build better by sharing *.o On Sun, Nov 9, 2014 at 5:07 AM, John Nemeth jnem...@cue.bc.ca wrote: On Nov 9, 1:25am, Masao Uebayashi wrote: } On Sat, Nov 8, 2014 at 11:53 PM, Christos

Re: MI linker script

On Sun, Nov 9, 2014 at 1:43 AM, Christos Zoulas chris...@astron.com wrote: In article cadbf7ecoaqbeuqjq5hq2ubpnkp4yftfre_tmakvtrdh_0hp...@mail.gmail.com, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 11:53 PM, Christos Zoulas chris...@astron.com wrote: depending on ld -r

Re: MI linker script

On Sun, Nov 9, 2014 at 11:22 AM, John Nemeth jnem...@cue.bc.ca wrote: The question wasn't simply about ld -r stuff. It was about the entire program of config(1) changes, linking changes, module(9) changes, etc. There's an awful lot of stuff happening to major parts of the system without

MI linker script

I want to make kernel linkage use MI linker script, so that MI ELF section/symbol handling is centralized into the one place. Instead of directly link *.o into netbsd, link an intermediate relocatable netbsd.ro. The downside of this is that build uses more disk space. I mean to compensate that

Re: MI linker script

Maybe I should rm the temporary *.ro immediately.

Re: MI linker script

On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas m...@3am-software.com wrote: linker scripts aren't used when doing -r. Not used implicitly. You can explicitly specify one. (I didn't know this fact one week ago. I understand your feeling.)

Re: MI linker script

On Sat, Nov 8, 2014 at 2:30 AM, Matt Thomas m...@3am-software.com wrote: On Nov 7, 2014, at 9:10 AM, Masao Uebayashi uebay...@gmail.com wrote: On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas m...@3am-software.com wrote: linker scripts aren't used when doing -r. Not used implicitly. You can

Re: MI linker script

For reference, this *actually* works, and intermediate *.ro is rm'ed. (This needs the uncommitted __SYMVAL() change in sys/cdefs_elf.h.) I'm not committing this soon, to give people time to overcome fear against ld -r. Index: sys/conf/Makefile.kern.inc

Re: state of XIP?

On Tue, Oct 15, 2013 at 4:17 PM, Matt Thomas m...@3am-software.com wrote: On Oct 14, 2013, at 11:41 PM, David Holland dholland-t...@netbsd.org wrote: Did uebayasi@'s XIP work get finished/committed? Which things does it work with? And (other than UTSL) where am I supposed to look to find out

Re: drivers customizing mmap(2)

On Wed, Mar 6, 2013 at 2:08 AM, Taylor R Campbell riastr...@netbsd.orgwrote: Date: Mon, 4 Mar 2013 19:15:37 -0600 From: David Young dyo...@pobox.com I thought that perhaps the device's cdevsw could provide an alternate to

Re: link_set info needed

link set won't work for modules. ISTR pooka@ did a work-around for RUMP or whatever. (Ideal alternative is decent ctors/dtors support.) On Thu, Apr 26, 2012 at 11:44 AM, Paul Goyette p...@whooppee.com wrote: I've been working on modularizing the ieee80211 code, and I've discovered that the

Re: Module name - recommendations/opinions sought

I thought module names alway match what's define'ed in config(1) files... ... and now I've found it's wlan, which should be changed to a saner name like net80211. On Thu, Apr 26, 2012 at 9:52 AM, Paul Goyette p...@whooppee.com wrote: I'm in the process of modularizing the ieee80211 (Wireless

Re: ChewieFS

IIUC ChewieFS follows FFS format, so the problem is block device driver. On Fri, Nov 11, 2011 at 9:15 PM, Tamas Toth tt...@inf.u-szeged.hu wrote: On Fri, 11 Nov 2011 05:06:13 +0100, Toru Nishimura locor...@alkyltechnology.com wrote: There are increasing number of NAND only (NOR less) embeded

Re: page color initialization

On Fri, Sep 30, 2011 at 1:13 PM, matthew green m...@eterna.com.au wrote: The current code seems to allow to change uvmexp.ncolors at configure() - cpu_attach() - uvm_page_recolor().  I think changing uvmexp.ncolors after uvm_init() is too late, and allocating such fundamental data like page

Re: netbsd-5 deadlocks when memory is low

On Thu, Sep 15, 2011 at 2:40 AM, Masao Uebayashi uebay...@gmail.com wrote: On Thu, Sep 15, 2011 at 2:13 AM, Emmanuel Dreyfus m...@netbsd.org wrote: Masao Uebayashi uebay...@gmail.com wrote: You're faulting on a busy (PG_BUSY) anon page whose owner is also an anon.  I suppose the page is being

Re: netbsd-5 deadlocks when memory is low

On Sat, Sep 17, 2011 at 10:28 AM, Emmanuel Dreyfus m...@netbsd.org wrote: Masao Uebayashi uebay...@gmail.com wrote: So what I can think of now is, the underlying bdev can't finish I/O because it allocates memory to handle I/O requests? I already spotted two points where ioflush was stuck

Re: Implement mmap for PUD

OK, I've re-read this topic. Your goal is to implement blktap on NetBSD/Xen, right? According to Xen wiki [1], blktap provides an interface for userland to handle block device I/O. I guess blktap gets inter-domain, shared ring memory from hypervisor. Dom0 userland mmaps the ring memory and

Re: Implement mmap for PUD

- pud_mmap in turn calls the parent blktap(4)'s mmap, which returns the ring buffers physical address - the ring buffer address is entered to MMU (udv_fault - pmap_enter) - userland can access shared ring memory On Sat, Sep 17, 2011 at 12:04 PM, Masao Uebayashi uebay...@gmail.com wrote: OK, I've re

  1   2   3   >