> On Dec 27, 2016, at 11:59 PM, Rin Okuyama wrote:
>
> Thank you for your kind explanation. I'm starting to understand.
> I will read again the reference manual from this point of view.
> So, could I commit the patch?
Go commit it.
> On Dec 27, 2016, at 10:49 PM, Rin Okuyama wrote:
>
> Thank you very much for your reply. I revised the patch accordingly, and
> it passed some stress tests on my OPENBLOCKS266.
>
> However, sorry for bothering you, but I don't understand why this work.
> The original DDB/IPKDB handlers use dd
Older ARM CPUs had the exeception page (page 0) that had to be mapped into the
user's address space. Fortunately that was solved in more recent ARMs with
HIGHVECTOR and now you actually set the base address for the exception vectors.
PowerPC has completely split user/kernel space so that addres
> On Dec 27, 2016, at 1:26 AM, Rin Okuyama wrote:
>
> I would like to fix port-powerpc/51367,
>
> http://gnats.netbsd.org/51367
>
> where ibm4xx-based machine is unstable with DDB option is specified.
>
> DDB hooks the program interrupt (EXC_PGM). In the privileged mode,
> this is OK. However
> On Dec 19, 2016, at 12:19 PM, Cherry G. Mathew wrote:
>
>Cherry> I believe, a more formal way to do this, would be to use the
> extent(9)
>Cherry> API to manage all of the paddr_t space, thus formalising this
>Cherry> relationship with consumers. I'm not inclined to look at this i
> On Jul 28, 2016, at 12:21 PM, Maxime Villard wrote:
>
> Le 28/07/2016 à 19:45, Eduardo Horvath a écrit :
>> On Thu, 28 Jul 2016, Maxime Villard wrote:
>>
>>> Currently, there is no real way to make sure a userland process won't be
>>> able to allocate the NULL page. There is this attempt [1],
> On Jul 23, 2016, at 1:36 AM, Maxime Villard wrote:
>
> Eight months ago, I shared with a few developers the code for a kernel
> interface [1] that can disable syscalls in user processes.
>
> The idea is the following: a syscall bitmap is embedded into the ELF binary
> itself (in a note sectio
> On Jun 21, 2016, at 8:30 AM, Michael wrote:
>
> Hello,
>
> On Tue, 21 Jun 2016 08:49:44 +
> co...@sdf.org wrote:
>
>> Replying to myself on tech-kern for the sake of completeness, in case
>> anyone has similar issues.
>>
>> For the failure of `cat hugefile.gz | gunzip -` I must use both
> 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 +0200
>> From: Joerg Sonnenberger
>>
>> On Mon, Jun 13, 2016 at 07:36:31PM +0900, Ryota Ozaki wrote:
>>> Currently we do it by open-codin
> On May 11, 2016, at 4:18 AM, SODA Noriyuki wrote:
>
> There are two points which need to be clarified.
>
> 1) The conf/majors files contains the following comment:
> # Majors 160-255 are used for the MI drivers.
> This "255" has to be changed, because the majors.storage file is
> al
> On Aug 21, 2015, at 10:32 PM, Thor Lancelot Simon wrote:
>
> Whoah. Why?
Because NFS marks mbufs as RO and the bus dma code did something
"special" for preparing a dma write into a readonly mbuf. Now
it just causes an assert to fire.
> On Aug 9, 2015, at 4:01 PM, Jeff Rizzo wrote:
>
> This would seem to indicate a problem with the particular interface (awge0),
> perhaps specific to the odroid-c1, as opposed to some l2 cache controller
> issue, which is kind of where I was leaning before. However, my banana pi
> has awge0
> On Jul 30, 2015, at 12:11 PM, Dennis Ferguson
> wrote:
>
> I know arm does double word ll/sc, but what else does?
> I don't know of a way to use single register ll/sc to do an
> atomic swap of two pointers.
Not many. running 32-bit on 64-bit CPUs.
You can do an atomic swap of a pointer to
sys/compat/netbsd32 is great at running 32-bit NetBSD on a 64-bit kernel.
But with a little tweaking, it could do so much more.
For example, aarch64 will need multiple instances of compat_netbsd32
(one for arm32 eabi, one for arm32 oabi, and possibly one for aarch64
ilp32 unless it can use the ar
> On Jun 26, 2015, at 8:17 AM, Antti Kantee wrote:
>
> Such as? I can only think of the "C debugging version" of simple_lock ;)
>
> Can't those be fixed by making them call __SIMPLELOCK_LOCKED_P()? They
> arguably should have been doing that in the first place anyway. Or are you
> worried
> On Jun 26, 2015, at 6:55 AM, Antti Kantee wrote:
>
> __cpu_simplelock_t was born 15+ years ago with the following commit message:
>
> === snip ===
> Let each platform typedef the new __cpu_simple_lock_t, which should
> be the most efficient type used for the atomic operations in the
> simplel
> On Jun 24, 2015, at 10:27 AM, Jeff Rizzo wrote:
>
> On 6/24/15 7:13 AM, matthew green wrote:
>> David Holland writes:
>>>
>>> I think keeping evb* for boards makes sense, though.
>> i dunno.
>>
>> i don't see what it adds. in particular, "evb" means evaluation
>> board, and there are heaps
> On Jun 23, 2015, at 12:17 PM, Reinoud Zandijk wrote:
>
> Hi Matt,
>
> On Sun, Jun 21, 2015 at 01:42:38PM -0700, Matt Thomas wrote:
>>> On Jun 21, 2015, at 12:02 PM, Reinoud Zandijk wrote:
>>> On Sun, Jun 21, 2015 at 08:01:47AM -0700, Matt Thomas wrote:
>
> On Jun 21, 2015, at 12:02 PM, Reinoud Zandijk wrote:
>
> Hi Matt,
>
> On Sun, Jun 21, 2015 at 08:01:47AM -0700, Matt Thomas wrote:
>> IMO, softints are an abberation and should really be thread priorities and
>> dealt by the thread scheduler.
>
> Each le
> On Jun 21, 2015, at 7:30 AM, Kamil Rytarowski wrote:
>
> I have got few questions regarding the interrupt flow in the kernel.
> Please tell whether my understanding is correct.
You are confusing interrupts with exceptions. Interrupts are
asynchronous events. Exceptions are (usually) synchr
> On Jun 3, 2015, at 10:05 PM, Aleksej Saushev wrote:
>
> Just in case you don't know, nearly any user has libxml2 and libxslt
> installed anyway.
None of my systems do.
Ultrix stopped supporting VAX with CVAX. NetBSD/vax supports later systems
like the VS4000s that are still quite zippy systems. A VS4000/96 is a really
nice box.
This is where retrocomputing NetBSD style shines.
The nice thing about old hardware is that bad design choice will likely be mor
> On May 29, 2015, at 1:31 PM, paul_kon...@dell.com wrote:
>
> No, transfering a whole file is a single stream of stuff; reading individual
> records is a more complex handshake. And apart from that, things get
> significantly simpler if you only support Sequential files. Simpler still if
>
> On May 28, 2015, at 4:15 PM, Johnny Billquist wrote:
>
> On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote:
>> paul_kon...@dell.com writes:
>>
>>> And DECnet nodes exist around the Internet; the “Hobbyist DECnet”
>>> group (“hecnet”) is the main focus of that activity as far as I know.
>>
>> ...
> On May 17, 2015, at 3:40 PM, Paul Goyette 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
> certain rout
> On May 14, 2015, at 8:17 AM, Christos Zoulas wrote:
>
> On May 14, 7:40pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> Thanks!
>
> Here's a slightly modified version that gets rid of the flags and simplifies
> the more common case.
>
> The follo
> On May 1, 2015, at 10:53 AM, David Holland wrote:
>
> On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote:
>> On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote:
>>> A quick look at build.sh shows that one of the first things that
>>> needs to be done is to map the MA
> On Apr 21, 2015, at 12:47 AM, Ryota Ozaki wrote:
>
> Hi,
>
> There are several if_type switches in if_vlan.c,
> which were introduced to support other hardware
> types such as FDDI many years ago. However, no
> implement hadn't come since then.
Doesn’t mean they aren’t correct. Leave them.
> On Apr 9, 2015, at 3:44 AM, Kengo NAKAHARA wrote:
>
> Hi,
>
> I implement x86 MD MSI/MSI-X support code. Here is the patch:
> http://www.netbsd.org/~knakahara/md-msi-msix/x86-md-msi-msix.patch
>
> Furthermore, here is the usage example of if_wm:
> http://www.netbsd.org/~knakahara/md-msi-
> On Feb 13, 2015, at 2:14 PM, Christos Zoulas wrote:
>
> In article <20150213192419.gb5...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
>>
>> I have asked the same question a long time ago when we pruned a bunch of
>> other obsolete emulations. From a security stand point, I fully agree
>
> On Dec 17, 2014, at 12:26 PM, Frank Zerangue wrote:
>
> I have a private port for an iMX31 based board which is itself based on
> evbarm. When I enable L2 cache in start.S the startup process freezes when I
> switch to the real L1 page table in initarm().
Don't do it that way. Make sure t
> On Dec 9, 2014, at 6:41 PM, Ryota Ozaki wrote:
>
> On Wed, Dec 10, 2014 at 11:29 AM, Thor Lancelot Simon wrote:
>> On Wed, Dec 10, 2014 at 11:19:52AM +0900, Ryota Ozaki wrote:
On Tue, Dec 9, 2014 at 1:17 PM, Thor Lancelot Simon wrote:
>
> Can you try increasing HZ?
T
> On Dec 8, 2014, at 4:58 PM, Frank Zerangue wrote:
>
> Can anyone tell me what work would be needed to add L2 cache support to the
> evbarm port?
L2 cache support is very SoC specific. Unless you tell us the target, we can't
help you.
Chances are that the L2 cache is already supported.
> On Nov 29, 2014, at 8:56 PM, Emmanuel Dreyfus wrote:
>
> Chuck Silvers wrote:
>
>> you can use msync() with MS_INVALIDATE.
>
> That cannot not help with vnode cached pages, right?
I use (cd /mntpnt && umount /mntpnt)
> On Nov 26, 2014, at 8:04 AM, Masao Uebayashi wrote:
>
> Critical section must stop soft interrupt which may block & sleep
> (using the preempted lwp). Thus critical sections must be at least
> IPL_SOFTSERIAL.
That is not true. If the softint thread sleeps, control is returned back
to the pr
> On Nov 8, 2014, at 11:16 PM, 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.
> But for the moment such a hardcoded priority should be good enough to improve
> m
> On Nov 7, 2014, at 9:10 AM, Masao Uebayashi wrote:
>
> On Sat, Nov 8, 2014 at 1:47 AM, Matt Thomas 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
> On Nov 7, 2014, at 6:53 AM, Masao Uebayashi wrote:
>
> 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 downsid
On Sep 23, 2014, at 11:24 AM, Christoph Egger wrote:
> Am 23.09.14 um 17:26 schrieb Matt Thomas:
>>
>> On Sep 23, 2014, at 6:47 AM, Taylor R Campbell wrote:
>>
>>> Date: Tue, 23 Sep 2014 15:41:25 +0200
>>> From: Martin Husemann
>>>
>&g
On Sep 23, 2014, at 6:47 AM, Taylor R Campbell wrote:
> Date: Tue, 23 Sep 2014 15:41:25 +0200
> From: Martin Husemann
>
> On Tue, Sep 23, 2014 at 01:38:53PM +, Taylor R Campbell wrote:
>> If it's GPL, we can make kernel modules.
>
> That is not very practical for display drivers o
On Sep 17, 2014, at 2:25 AM, Kamil Rytarowski wrote:
> Hello,
>
> This is the first status of significant efforts of porting AdvFS [1] [2] to
> NetBSD.
>
> Long term primary goals:
> - complete port of AdvFS to NetBSD,
> - relicense the original work with for BSD-friendly license.
I tried to
On Sep 15, 2014, at 4:59 PM, Patrick Welche wrote:
> On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
>> On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
>>> Given a filedescriptor, how can you tell that it is valid and has been
>>> opened?
>>>
>>> In the attached simple
On Sep 7, 2014, at 8:51 PM, Kengo NAKAHARA wrote:
> Hi,
>
> Thank you for answer.
>
> (2014/09/08 12:34), Matt Thomas wrote:
>>
>> On Sep 7, 2014, at 7:28 PM, Kengo NAKAHARA wrote:
>>
>>> I have a question about kcpuset. Referring "man 9
On Sep 7, 2014, at 7:28 PM, Kengo NAKAHARA wrote:
> I have a question about kcpuset. Referring "man 9 kcpuset", the APIs
> need cpuid (the type is cpuid_t) to identify CPU. However, the callers
> such as idle_loop() sys/kern/kern_idle.c use cpu index (the type is u_int).
>
> cpu index means ret
On Aug 29, 2014, at 1:27 PM, David Young wrote:
> bus_msi(9) gives MI code access to doorbells: MI code uses it to
> establish a doorbell -> interrupt handler mapping and find out the
> doorbell's physical address.
>
> All the code to map the doorbell's physaddr into a PCI busaddr, to
> program
On Aug 26, 2014, at 11:16 PM, Kengo NAKAHARA wrote:
> It seems good, except return value. IRQ affinity may fail (e.g. when
> all cpus are set "nointr" flag), so return value should not be void.
then we should have a kcpuset_interruptable which is kcpuset_running
minus those cpus which have noin
As I've been reading this discussion, it seems very x86 centric.
I've thinking about adding
void intr_distribute(void *ih, const kcpuset_t *newset, kcpuset_t *oldset)
for my ports that can do MP. This could be used to obtain the current
set of cpus setup to receive interrupt for or set a new
On Jul 27, 2014, at 7:09 AM, Thor Lancelot Simon wrote:
>
> Same system I have; same symptom I have. Though I don't have any drive
> that works. We do correctly probe that a target is present and we get
> the link speed right at 6.0 Gbit/sec (though we seem to also probe another
> spurious tar
On Jul 19, 2014, at 2:02 AM, Alexander Nasonov wrote:
> To compile in rump kernel, I needed to add -DMIPS3=1
> to Makefile.rump for mips platforms. This is the only change outside
> of sljit scope.
the cache instructions are privileged. There's a sysarch interface
that you can use the clean t
On Jul 3, 2014, at 6:26 AM, Maxime Villard wrote:
> Le 02/07/2014 07:01, David Holland a écrit :
>>
>> On Tue, Jul 01, 2014 at 07:38:33PM +0100, Justin Cormack wrote:
>>> FreeBSD recently (
>>> http://svnweb.freebsd.org/base?view=revision&revision=264269 ) added
>>> elf header signature parsing
On Jun 24, 2014, at 10:43 PM, Ryota Ozaki wrote:
> Hi,
>
> I found a strange behavior of if_wm that
> its interrupt handler may call its if_start
> (xmit function) eventually. I don't think
> it's sane. It makes difficult to use mutex for MP.
>
> Here is a call trace:
> wm_intr => wm_linkintr
On Jun 21, 2014, at 9:48 PM, Darren Reed wrote:
> On 22/06/2014 8:13 AM, Matt Thomas wrote:
>> On Jun 21, 2014, at 4:56 AM, Darren Reed wrote:
>>> On 21/06/2014 11:00 AM, Matt Thomas wrote:
>>>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki wrote:
>>>>
&g
On Jun 21, 2014, at 5:56 AM, Ryota Ozaki wrote:
> On Sat, Jun 21, 2014 at 10:00 AM, Matt Thomas wrote:
>>
>>
>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki wrote:
>>
>>> Hi,
>>>
>>> I've prepared a trial patch of MPSAFE network
On Jun 21, 2014, at 4:56 AM, Darren Reed wrote:
> On 21/06/2014 11:00 AM, Matt Thomas wrote:
>> On Jun 20, 2014, at 5:57 AM, Ryota Ozaki wrote:
>>
>>> Hi,
>>>
>>> I've prepared a trial patch of MPSAFE networking.
>>>
>>> http
On Jun 20, 2014, at 5:57 AM, Ryota Ozaki wrote:
> Hi,
>
> I've prepared a trial patch of MPSAFE networking.
>
> http://www.netbsd.org/~ozaki-r/mpsafe-wm.diff
>
The kmutex_t in ifqueue, etc. should be pointers and not in the structure
themselves.
That can simply the macros to test for a NUL
On Jun 6, 2014, at 12:06 PM, Taylor R Campbell
wrote:
> Date: Fri, 6 Jun 2014 12:56:53 -0500
> From: David Young
>
> Here is the proposal that I came up with many months (a few years?) ago
> with input from Matt Thomas. I have tried to account for Matt's
>
On Jun 6, 2014, at 10:40 AM, David Young wrote:
> On Fri, May 30, 2014 at 05:55:25PM +0900, Kengo NAKAHARA wrote:
>> Hello,
>>
>> I'm going to add MSI/MSI-X support to NetBSD. I list tasks about this.
>> Would you comment following task list?
>
> I think that MSI/MSI-X logically separates into
On Jun 6, 2014, at 10:40 AM, David Young wrote:
> 1 An MI API for establishing "mailboxes" (or "doorbells" or whatever
> we may call them). A mailbox is a special physical address (PA) or
> PA/data-pair in correspondence with a callback (function, argument).
>
> An MI API for mapping the ma
On Jun 5, 2014, at 8:47 AM, Martin Husemann wrote:
> On Thu, Jun 05, 2014 at 03:36:37PM +, Eduardo Horvath wrote:
>> Have you tested this?
>
> I ran an install on a 8 MB simh VAX, and it worked good enough for that.
> No, I wouldn't call that serious testing.
can you try using freetarg?
On May 20, 2014, at 4:20 PM, Taylor R Campbell wrote:
> Date: Tue, 20 May 2014 13:54:44 -0700
> From: Matt Thomas
>
> Wrong approach. These should be on dedicated vm freelists instead.
> Look at how mips64 has first512m, first4g, etc. You could have
> first4g,
On May 20, 2014, at 1:40 PM, Taylor R Campbell wrote:
> DRM/GEM uses uvm_aobj for long-term pageable graphics buffers, but
> when these buffers are assigned physical pages whose addresses can be
> programmed into the GPU's page tables, only certain physical pages are
> allowed -- specifically, I
On Apr 18, 2014, at 11:23 AM, Markku-Juhani Olavi Saarinen wrote:
> It has been there on all new systems purchased in some last 3 years,
> so I would *guess* that it would be > 50% of systems fielded out
> there.
Not everything is x86 based.
I recently ordered an ODROID-XU Lite to help beat on the my ARM MP code.
However, it has a quirk that I don't think our scheduler will deal with.
It has 4 Cortex-A15 cores @ 1.4Ghz and 4 Cortex-A7 cores @ 1.2Ghz. Even if the
frequencies weren't different, the A15 cores at least twice as fast p
On Mar 26, 2014, at 6:03 PM, David Holland wrote:
> http://www.dragonflybsd.org/presentations/nanosleep/
>
> Can someone who's familiar with the timecounter code (that is, not me)
> look at this and see if we can steal their fixes?
The problem isn't timecounter, it's hardclock and the callout
On Mar 7, 2014, at 8:32 AM, Andreas Gustafsson wrote:
> Thor Lancelot Simon wrote:
>>> An application could, for example, maintain a single, shared,
>>> malloc'ed buffer that is reused for multiple sysctl() calls and only
>>> resized on ENOMEM returns. IMO, this is allowed by the API, but with
On Feb 22, 2014, at 2:04 PM, Mindaugas Rasiukevicius wrote:
> Matt Thomas wrote:
>>
>> I've been wondering...
>>
>> Should pmap_kenter_pa overwrite an existing entry should it be operating
>> on an unmapped VA.
>
> You mean already mapped VA?
I
I've been wondering...
Should pmap_kenter_pa overwrite an existing entry should it be operating
on an unmapped VA. I think that if you want to change a mapping, you
should do a pmap_kremove first.
On Feb 19, 2014, at 8:34 AM, David Holland wrote:
> On Mon, Feb 17, 2014 at 09:25:49PM +, David Laight wrote:
I'm adding code to i386 and amd64 to save the ymm registers on process
switch - allowing userspace to use the AVX instructions.
[ensuing crap about the u area]
>>>
>>
On Feb 18, 2014, at 3:54 AM, Yann Sionneau wrote:
> Le 10/02/14 23:00, Yann Sionneau a écrit :
>> Thanks for all your explanations, if everything I said here is correct
>> (which would mean I understood correctly your answer) then I think I'm ready
>> to implement all this :)
>
> Hi,
>
> I h
On Feb 16, 2014, at 1:41 PM, David Laight wrote:
> I'm adding code to i386 and amd64 to save the ymm registers on process
> switch - allowing userspace to use the AVX instructions.
>
> I also don't want to have to do it all again when the next set of
> extensions appear.
> This means that the s
On Feb 10, 2014, at 2:00 PM, Yann Sionneau wrote:
> So if I understand correctly I could implement the following scheme:
>
> Let my linker put the kernel ELF virtual addresses to 0xc000.. Load the
> kernel at base of RAM (0x4000.)
> Then reserve this memory region as a "window" over ph
On Feb 10, 2014, at 9:10 AM, Eduardo Horvath wrote:
> On Sun, 9 Feb 2014, Yann Sionneau wrote:
>
>> Thank you for your answer Matt,
>>
>> Le 09/02/14 19:49, Matt Thomas a écrit :
>>> On Feb 9, 2014, at 10:07 AM, Yann Sionneau wrote:
>
>
>>>&g
On Feb 9, 2014, at 10:07 AM, Yann Sionneau wrote:
> This seems like the easiest thing to do (because I won't have to think about
> recursive faults) but then if I put physical addresses in my 1st level page
> table, how does the kernel manage the page table entries?
BookE always has the MMU o
On Feb 1, 2014, at 4:49 PM, Emmanuel Dreyfus wrote:
> Matt Thomas wrote:
>
>> You only need one sep32 and then copyout each entry:
>
> Isn't there a performance impact to call copyout several times instead
> of one?
Compared to kmem_alloc/kmem_free? Notice we ar
On Feb 1, 2014, at 12:41 AM, Emmanuel Dreyfus wrote:
> + int count = SCARG(uap, misc);
> + int i, error;
> +
> + sep = kmem_alloc(sizeof(*sep) * count, KM_SLEEP);
> + sep32 = kmem_alloc(sizeof(*sep32) * count, KM_SLEEP);
Before using count, one must limit it using:
On Jan 31, 2014, at 11:46 AM, Martin Husemann wrote:
> On Fri, Jan 31, 2014 at 03:03:21PM +, Justin Cormack wrote:
>> Linux maps the kernel with 4MB pages to save TLB entries too, I believe.
>
> Yes, we do that too, but I guess wired kernel memory does not really
> count for Matt's proposal
Instead of the system sharing a common page size, the page size would be
dependent on what the pmap for that address range wants. Note that different
processes (vmspaces) could have different page sizes. The kernel could have
a different page than user processes.
NBPG/PAGE_SIZE as globals wou
On Dec 4, 2013, at 1:33 PM, Alan Barrett wrote:
> On Wed, 04 Dec 2013, David Holland wrote:
>> (*) A complete scheme for doing it right removes all the _BSD_FOO_T_
>> drivel and ifdefs scattered in userland headers in favor of:
>> - a single header file that defines all the needed types prefixe
On Dec 3, 2013, at 7:25 PM, Lourival Vieira Neto
wrote:
> Hi Matt,
>
>>> Is there a reason to do not have ptrdiff_t defined in the kernel?
>>> Shouldn't be OK to define it in sys/cdefs.h? Or even for having
>>> stddef.h itself in the kernel?
>>
>> It is defined in the kernel and comes from v
On Dec 2, 2013, at 5:58 PM, Lourival Vieira Neto
wrote:
> Hi Folks,
>
> Is there a reason to do not have ptrdiff_t defined in the kernel?
> Shouldn't be OK to define it in sys/cdefs.h? Or even for having
> stddef.h itself in the kernel?
It is defined in the kernel and comes from via
.
No,
On Nov 15, 2013, at 10:56 AM, Lars Heidieker wrote:
> Matt, you mean allocating and freeing memory from softint context should
> be ok? That's something that went through my mind as well and I think
> it's the right way.
I do. softint routines can wait for mutexes so allocation in them should
On Nov 15, 2013, at 6:22 AM, Christoph Badura wrote:
> While trying to port BCM586x support I discovered that I get the following
> panic under -current. The same code works fine on -6. What gives?
>
> panic: kernel diagnostic assertion "((!cpu_intr_p() && !cpu_softintr_p()) ||
> (pc->pc_poo
On Nov 12, 2013, at 11:47 AM, Michael van Elst wrote:
> m...@3am-software.com (Matt Thomas) writes:
>
>
>> On Nov 11, 2013, at 10:08 PM, Michael van Elst wrote:
>
>>> The "slowdown" is already enormous due to lack of floating point
>>> hardw
On Nov 11, 2013, at 10:08 PM, Michael van Elst wrote:
> The "slowdown" is already enormous due to lack of floating point
> hardware. That's why emulating the FP hardware is a very common
> way to handle this situation, just look at the other platforms.
The exception handling is much costlier th
On Nov 12, 2013, at 9:33 AM, Dennis Ferguson
wrote:
> - Some attention should be given to figuring out what runs on what. Even
> if I've compiled the base system for my BeagleBone for earmv7hf myself,
> it would be nice to still be able to install pkgsrc binaries built for
> the RPi if that
On Nov 12, 2013, at 9:33 AM, Dennis Ferguson
wrote:
>
> On 11 Nov, 2013, at 15:31 , Justin Cormack
> wrote:
>> On Mon, Nov 11, 2013 at 10:56 PM, Michael van Elst
>> wrote:
>>> m...@3am-software.com (Matt Thomas) writes:
>>>
>>>> Exa
On Nov 11, 2013, at 8:33 PM, Warner Losh wrote:
> Is there a complete write up of the conventions here?
Conventions?
earm{v[4567],}{hf,}{eb} except earmv4hf isn’t valid.
Due to recent GCC changes, the earmv6* and earmv7* not only will have
instructions that execute on pre-armv6 CPUs they wi
On Nov 10, 2013, at 2:24 PM, Justin Cormack
wrote:
> On Sun, Nov 10, 2013 at 9:48 PM, Matt Thomas wrote:
>> I strongly disagree with that. I specifically choose use different machine
>> arches so that the hard/soft float binary packages would be separate.
>> From
On Nov 10, 2013, at 1:39 PM, Alistair Crooks wrote:
> On Sun, Nov 10, 2013 at 01:20:41PM -0800, Matt Thomas wrote:
>> Exactly. with hf, floating point values are passed in floating point
>> registers. That can not be hidden via a library (this works on x86
>> since
On Nov 10, 2013, at 12:57 PM, Justin Cormack
wrote:
> On Sun, Nov 10, 2013 at 7:38 PM, Alistair Crooks wrote:
>> On Sun, Nov 10, 2013 at 04:56:04AM +, Jun Ebihara wrote:
>>> Module Name: pkgsrc
>>> Committed By: jun
>>> Date: Sun Nov 10 04:56:04 UTC 2013
>>>
>>> Modified Files:
>
On Nov 1, 2013, at 12:53 PM, Mouse wrote:
>>> Also, see below - 1ms strikes me as pretty bad for PPS.
>> Sure, but it's vastly better than nmea timecode, which is what the
>> other choice is.
>
> Oh, sure; as I said in other words upthread, I'm not arguing that it's
> not a good choice for you
On Oct 26, 2013, at 10:54 AM, Izumi Tsutsui wrote:
>>> By static MACHINE_ARCH, or dynamic sysctl(3)?
>>> If dynamic sysctl(3) is prefered, which node?
>>
>> hw.machine_arch
>>
>> which has been defined for a long long time.
>
> Yes, defined before sf vs hf issue arised, and
> you have changed
On Oct 26, 2013, at 5:45 AM, Izumi Tsutsui wrote:
> By static MACHINE_ARCH, or dynamic sysctl(3)?
> If dynamic sysctl(3) is prefered, which node?
hw.machine_arch
which has been defined for a long long time.
On Oct 19, 2013, at 12:26 AM, Marc Balmer wrote:
> Am 19.10.13 09:03, schrieb Alan Barrett:
>> On Sat, 19 Oct 2013, Marc Balmer wrote:
>>> The inclusion and use of Lua in base, for use in userland and the
>>> kernel, [...] has, last but not least, core's blessing.
>>
>> Would you please either
On Oct 18, 2013, at 1:06 AM, David Holland wrote:
>> The only problem is marking data as copy-on-write
>> but again these pages aren't managed so the current COW code won't
>> be happy.
>
> We shouldn't have to care about that unless we want to move to
> MAP_COPY from MAP_PRIVATE.
Huh? I'm wa
On Oct 17, 2013, at 10:41 PM, David Holland wrote:
> If the XIP code is not mergeable, what's entailed in doing a different
> implementation that would be? Also, is the getpages/putpages interface
> expressive enough to allow doing this without major UVM surgery? For
> now I'm assuming a file sy
On Oct 17, 2013, at 4:57 AM, Izumi Tsutsui wrote:
> Anyway, our commit guidelines explicitly require Core's approval
> before adding a new package into base. You violate the rule.
> That's the enough reason to revert your commit without discussion.
He did get core's approval and core did requi
On Oct 15, 2013, at 12:09 AM, Marc Balmer wrote:
> In a tty line discipline, I want to get the name of the tty driver
> instance, e.g. "dtyU0". The line disciplines are called with a "struct
> tty *" as argument, is there any (halfway sane) way to get at the name
> of the driver instance? I ne
On Oct 14, 2013, at 11:41 PM, David Holland 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 more?
It was not committed since core felt that it needed too many kludges
to properly work.
A lot of systems are coming with compute/peripheral processors with
limited ram, etc.
I was wondering what the abstraction should be?
Obviously, mmap()'ing their memory would be nice. But what about
stopping/starting? Messaging?
Ideas are welcome.
1 - 100 of 266 matches
Mail list logo
