On Sat, Feb 20, 2016 at 08:34:07AM -0600, Jonathan A. Kollasch wrote:
> The aprint_*(9) functions are *only* suitable for use within
> autoconf(9) code. The printf(9) or log(9) functions need to be used if
> it is not autoconf(9)-related. There is existing code that abuses
> aprint_*(), please fi
On Fri, Feb 19, 2016 at 08:29:35PM +0900, Kengo NAKAHARA wrote:
> Hi,
>
> On 2016/02/19 19:38, Joerg Sonnenberger wrote:
> > On Fri, Feb 19, 2016 at 06:26:14PM +0900, Kengo NAKAHARA wrote:
> >> Of course, m_tag_get() is used by packet processing path, this overhead
&
On Fri, Feb 19, 2016 at 06:26:14PM +0900, Kengo NAKAHARA wrote:
> Of course, m_tag_get() is used by packet processing path, this overhead
> would have a certain influence on packet throughput and latency.
> So, I think m_tag should use a dedicated pool cache like mbuf to call
> pool_cache_get() dir
On Mon, Feb 15, 2016 at 01:42:51PM +0100, Edgar Fuß wrote:
> Is there a special reason for rccide not being listed (not even commented
> out)
> in the amd64 GENERIC kernel configuration?
> Are there any known issues with that driver?
Do they exist as actual PCI(e) cards or only onboard? If the l
On Wed, Feb 03, 2016 at 06:43:58PM +0100, Edgar Fuß wrote:
> > Is this down to the kern.no_sa_support sysctl?
> Hm, probably yes. What's the point of that variable (I couldn't find
> anything useful in the archives)? At a first glance, it looks like
> kern.partly_break_4_compatibility_on_purpose.
On Wed, Feb 03, 2016 at 04:42:32PM +0100, Edgar Fuss wrote:
> I tried updating a 4.0.1 machine (amd64) to 6.1 by first updating the kernel
> and I get a ``libpthread: sa_register failed: Invalid argument'' (when trying
> to start nslcd). Any hints?
Scheduler activation has been fully removed. If
On Tue, Jan 26, 2016 at 08:45:10AM -0500, Christos Zoulas wrote:
> On Jan 26, 6:17am, dholland-t...@netbsd.org (David Holland) wrote:
> -- Subject: Re: cookies and kmem_alloc
>
> | On Mon, Jan 25, 2016 at 02:31:15PM -0500, Christos Zoulas wrote:
> | > The directory functions pass around ap_cooki
On Tue, Jan 19, 2016 at 10:25:46AM -0800, Chuck Silvers wrote:
> I wouldn't want it as a default for everything either, it breaks things like
> xbiff.
> the linux "relatime" thing seems like a reasonable compromise.
Haven't we been implementing relatime effectively forever? I thought
atime change
On Thu, Jan 14, 2016 at 07:19:03PM +0900, Ryota Ozaki wrote:
> One possible objection should be performance
> degradation, however I believe we can mitigate
> by introducing polling packet processing
> like Linux and FreeBSD do. Of course, we also
> have to rethink existing sofint (L3 softints
> an
On Mon, Oct 12, 2015 at 09:40:09PM +0200, Joerg Sonnenberger wrote:
> I have a build machine building pkgsrc where I see some very strange
> issues. The individual chroots share a read-only null-mounted base
> directory with a number of tmpfs instances on top for most of the
> wri
On Fri, Dec 11, 2015 at 11:00:06AM -0500, Christos Zoulas wrote:
> Perhaps we should just explain that it is not the responsibility of the
> caller to check for the result of kmem_alloc() in the KM_WAIT case, and
> centralize the check in kmem_alloc() to make it panic() if it would
> return NULL? I
On Sat, Nov 28, 2015 at 07:54:10PM +0100, Maxime Villard wrote:
> here is a (draft) patch to map the kernel DATA and BSS segments with
> the NX/XD bit in the PTEs on i386+amd64.
There should be no need to force extra padding between .data and .bss.
Joerg
On Mon, Oct 12, 2015 at 09:40:09PM +0200, Joerg Sonnenberger wrote:
> I have a build machine building pkgsrc where I see some very strange
> issues. The individual chroots share a read-only null-mounted base
> directory with a number of tmpfs instances on top for most of the
> wri
On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
> Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
> optional.
See part about modularity masturbation. Making things optional for the
sake of making them optional is just as wrong.
> Both EXEC_SCRIPT and COREDUMP are
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 rationale that makes POSIX sempahores a
> >>non-opti
On Sat, Nov 07, 2015 at 10:55:49AM +0800, Paul Goyette wrote:
> I'd like to understand the rationale that makes POSIX sempahores a
> non-optional component of the kernel, while POSIX message queues are
> still optional. Both seem to be related specifically to use in the
> librt real-time library.
Hi all,
I have a build machine building pkgsrc where I see some very strange
issues. The individual chroots share a read-only null-mounted base
directory with a number of tmpfs instances on top for most of the
writeable parts. Symptoms of the some data corruption or race
conditions:
(1) checksum f
On Sat, Oct 03, 2015 at 04:29:23PM +0200, Jean-Yves Migeon wrote:
> Le 03/10/2015 15:45, Joerg Sonnenberger a écrit :
> > On Sat, Oct 03, 2015 at 02:46:26PM +0200, Maxime Villard wrote:
> >> You can see that the pointer given to kmem_free() is not the one kmem_alloc
> >
On Sat, Oct 03, 2015 at 02:46:26PM +0200, Maxime Villard wrote:
> You can see that the pointer given to kmem_free() is not the one kmem_alloc
> returned. Actually, I don't understand at all what this code is supposed to
> do. Found by Brainy.
It tries to make sure the pointer has a certain alignme
On Mon, Sep 14, 2015 at 11:15:34PM -0400, Michael McConville wrote:
> I suspect that this preproc condition isn't necessary anymore? It's in
> sys/sys/device.h:246.
We require C99 support for the kernel, so no, just use FMA.
Joerg
On Sat, Sep 12, 2015 at 02:23:38PM +0200, Matthias-Christian Ott wrote:
> On 2015-08-09 14:26, Joerg Sonnenberger wrote:
> > On Fri, Jul 31, 2015 at 10:25:32AM +, Matthias-Christian Ott wrote:
> >> queue.h defines initializers macros (e.g. LIST_HEAD_INITIALIZER) and
> >
On Mon, Sep 07, 2015 at 09:23:21AM +0200, Martin Husemann wrote:
> On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski wrote:
> > + error = vnode_to_path(path, MAXPATHLEN,vp, l, p);
>
> Two nits:
>
> 1) vnode_to_path(9) is undocumented
> 2) it only works if you are lucky (IIUC) - which
On Wed, Aug 19, 2015 at 09:51:29AM -0400, Thor Lancelot Simon wrote:
> We should be shipping with DIRHASH turned on.
You got it disabled, have you changed your mind?
Joerg
On Tue, Aug 18, 2015 at 03:31:45PM +0200, J. Hannken-Illjes wrote:
> On 18 Aug 2015, at 15:06, Joerg Sonnenberger wrote:
>
> > On Tue, Aug 18, 2015 at 01:06:02PM +0200, J. Hannken-Illjes wrote:
> >> And our memcmp is slw ...
> >
> > Do you have any
On Tue, Aug 18, 2015 at 01:06:02PM +0200, J. Hannken-Illjes wrote:
> And our memcmp is slw ...
Do you have any thing substancial to justify this?
Joerg
On Sun, Aug 09, 2015 at 02:46:44PM -0400, Thor Lancelot Simon wrote:
> On Sun, Aug 09, 2015 at 02:25:08PM +0200, Joerg Sonnenberger wrote:
> > On Thu, Jul 30, 2015 at 06:23:33PM +, Taylor R Campbell wrote:
> > >I don't think you can have a portable function like that
On Fri, Jul 31, 2015 at 10:25:32AM +, Matthias-Christian Ott wrote:
> queue.h defines initializers macros (e.g. LIST_HEAD_INITIALIZER) and
> initialization macros (e.g. LIST_INIT). The initializer macros have been
> introduced in NetBSD. I'm not sure how what's the intended purpose of
> both ma
On Thu, Jul 30, 2015 at 06:23:33PM +, Taylor R Campbell wrote:
>I don't think you can have a portable function like that.
>
> Not that hard:
>
> - On i386, use cmpxchg8b.
Just for the archive, this effectively means Pentium+. There are
actually 486-class SMP systems.
Joerg
On Sun, Jul 05, 2015 at 10:33:02PM -0700, Dennis Ferguson wrote:
> If you don't want it to work this way then you'll need to replace the
> radix tree with something that permits changes while readers are
> concurrently operating. To take best advantage of a more modern data
> structure, however, y
On Wed, Jul 08, 2015 at 09:28:01PM -0700, Dennis Ferguson wrote:
> What this means is that your proposed use of the next
> hop IP address is a gratuitous indirection; you would be taking
> something which would be best done as
>
> ->
>
> and instead turning this into
>
> -> -> ->
>
On Sun, Jul 05, 2015 at 02:12:18PM +0900, Ryota Ozaki wrote:
> On Sun, Jul 5, 2015 at 2:35 AM, David Young wrote:
> > On Sat, Jul 04, 2015 at 09:52:56PM +0900, Ryota Ozaki wrote:
> >> I'm trying to improve use of rt_refcnt: reducing
> >> abuse of it, e.g., rt_refcnt++/rt_refcnt-- outside
> >> rout
On Wed, Jul 01, 2015 at 07:21:17PM +, Taylor R Campbell wrote:
>Date: Wed, 1 Jul 2015 18:56:20 +
>From: David Holland
>
>On Wed, Jul 01, 2015 at 06:38:54PM +, Taylor R Campbell wrote:
> > There's a patch floating around to ascertain how much space is left in
> > th
On Wed, Jul 01, 2015 at 06:57:26PM +0200, Emmanuel Dreyfus wrote:
> Martin Husemann wrote:
>
> > > Then it should not be an option.
> > It is a real option on some other architecturs, so this gets tricky.
>
> At least it should be documented as such: options(4) can note it is
> implicit x86 and
On Wed, Jul 01, 2015 at 10:48:29PM +1000, matthew green wrote:
>
> last i tried, it was only a couple of minor fixes needed
> to make x86 build without MULTIPROCESSOR.
The only reason I know why you would want that is to disable the use of
the LAPIC. Everything else can either be done via boot -1
On Wed, Jul 01, 2015 at 07:20:14PM +0800, Paul Goyette wrote:
> On Wed, 1 Jul 2015, Joerg Sonnenberger wrote:
>
> >On Wed, Jul 01, 2015 at 08:01:30AM +, Emmanuel Dreyfus wrote:
> >>In -current, x86 seems to be unable to build withotu MUTLIPROCESSOR:
> >>src/sys
On Wed, Jul 01, 2015 at 08:01:30AM +, Emmanuel Dreyfus wrote:
> In -current, x86 seems to be unable to build withotu MUTLIPROCESSOR:
> src/sys/kern/kern_stub.c:195:5: error: #error __HAVE_PREEMPTION requires
> MULTIPROCESSOR
Yes, the option is required.
Joerg
On Wed, Jun 17, 2015 at 10:14:53PM +0200, Reinoud Zandijk wrote:
> I.e. instead of having formats dictate the wedges, have LVM dictate the
> (hidden) backend encoding needed for say booting? While still have all the
> configurability like growing/shrinking/moving/joining etc?
That makes no sense.
On Wed, Jun 03, 2015 at 10:21:11PM +0200, deco33...@yandex.com wrote:
> Convergence of efforts, cleanness of design, well understood by
> everybody, tackles the a20 gate, and all the _very_ boring heritage
> for us.
All of that is very well understood and any kernel with least 15 years
of x86 hist
On Wed, Jun 03, 2015 at 10:02:32PM +0200, deco33...@yandex.com wrote:
> "which kind of defeats having a high level boot loader in first place"
>
> Not if you plan to have multiple OS on the same hdd. Other than that, I fully
> agree.
But multiboot is meant to replace the custom boot protocols an
On Wed, Jun 03, 2015 at 10:09:49AM +0200, Sheda wrote:
> I confirm the amd64 port is not multiboot compliant,
> arch/amd64/amd64/locore.S lake the multiboot header you can see in its
> i386 counterpart:
> http://fxr.watson.org/fxr/source/arch/i386/i386/locore.S?v=NETBSD#L261
That statement is kind
On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote:
> Asking for ARCNET support in the absence of hardware to test on,
> however, is really asking for something quite different. Since you
> can't make more than small, mechanical changes to anything and expect
> it to work without test
On Fri, May 29, 2015 at 09:38:06PM -0300, Dimitri Berveglieri wrote:
> The best way to be good is work in a real project and i really believe in
> NetBSD.
>
> Can you give me a chance?
Of course :) Do you have something that interests you?
Joerg
On Wed, May 20, 2015 at 12:01:19PM +0900, Ryota Ozaki wrote:
> There remain some stuffs of retired netns in the
> source code. This attempt removes references to
> AF_NS and NS option (and NETISR_NS definition).
>
> Here is a patch:
> http://www.netbsd.org/~ozaki-r/remove-netns.diff
>
> Any objec
On Wed, May 13, 2015 at 01:52:05PM +0200, Kamil Rytarowski wrote:
> A FreeBSD developer studying our examples told me that we traditionally use
> u_int in place of unsigned [int] - calling the usage of 'unsigned' a linuxism.
> I have no opinions on it. How is it?
Personally, I consider the use of
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 MACHINE name to the CPU architecture
> name, i.e. MACHINE_ARCH. I noticed that some ports set
> MACHINE=MACHINE_ARCH, but some others do
On Wed, Apr 29, 2015 at 03:32:14AM +0200, Kamil Rytarowski wrote:
> http://www.nongnu.org/libunwind/docs.html
>
> Can you propose an alternative to making libunwind work on NetBSD?
The first two hyperlinks in the related section actually describe the
much saner interface people should be using.
On Tue, Apr 28, 2015 at 01:45:13PM +0200, Kamil Rytarowski wrote:
> From what I can see these numbers are standardized across systems (Linux,
> FreeBSD).
Not really.
> I need libunwind (a dependency of quite few runtimes) for NetBSD and I just
> landed here.
I still maintain that any runtime d
On Mon, Mar 23, 2015 at 07:36:52AM +, Taylor R Campbell wrote:
>Date: Sat, 21 Mar 2015 16:20:32 +0100
>From: Joerg Sonnenberger
>
>My consideration is for the future of when the callout handling itself
>uses precise times. In that cacse, bintime does simpl
On Sat, Mar 21, 2015 at 10:34:34AM +, Taylor R Campbell wrote:
>Date: Fri, 20 Mar 2015 18:37:50 +0100
>From: Joerg Sonnenberger
>
>On Fri, Mar 20, 2015 at 01:37:59PM +, Taylor R Campbell wrote:
>> Objections?
>
>Only thing to consider is whe
On Fri, Mar 20, 2015 at 01:37:59PM +, Taylor R Campbell wrote:
> Objections?
Only thing to consider is whether we want to hardwire timespec here or
not switch to bintime. It makes for nicer computations in the rest of
the code later.
Joerg
On Tue, Mar 17, 2015 at 11:48:51AM +0100, Martin Husemann wrote:
> On Tue, Mar 17, 2015 at 11:39:44AM +0100, Joerg Sonnenberger wrote:
> > > No, you should not randomly add the expensive ptyfs code to INSTALL
> > > kernels
> > > you can not test yourself. Everything
On Tue, Mar 17, 2015 at 09:56:18AM +0100, Martin Husemann wrote:
> On Mon, Mar 16, 2015 at 02:02:11PM -0400, Christos Zoulas wrote:
> > My vote is to keep compat code, add ptyfs to all install kernels, and
> > try mounting ptyfs from sysinst before openpty.
>
> No, you should not randomly add the
On Fri, Mar 13, 2015 at 03:36:38PM -0400, Christos Zoulas wrote:
> I was trying to avoid carrying over the old pty code around forever,
> and having all the ports doing it in a unified way. I guess it does
> not matter too much for the installer, but it does add complexity...
> I think if you remov
On Mon, Mar 02, 2015 at 01:50:34PM +0100, Tom Ivar Helbekkmo wrote:
> Joerg Sonnenberger writes:
>
> > Just in case others run into it, you can put the patch you are running
> > into GNATS?
>
> Yes, of course. Should I submit it as a bug report with a known
> w
On Mon, Mar 02, 2015 at 09:47:10AM +0100, Tom Ivar Helbekkmo wrote:
> Joerg Sonnenberger writes:
>
> > If it still generates interrupts, there is not much we can do. I do not
> > believe turning off interrupts on the PIC is in any way appropiate.
>
> I've been runni
On Tue, Feb 17, 2015 at 01:47:50PM +0100, Tom Ivar Helbekkmo wrote:
> Joerg Sonnenberger writes:
>
> > If it still generates interrupts, there is not much we can do. I do not
> > believe turning off interrupts on the PIC is in any way appropiate.
>
> All right, but be
On Tue, Feb 17, 2015 at 08:41:25AM +0100, Tom Ivar Helbekkmo wrote:
> Joerg Sonnenberger writes:
>
> > (1) It's a shared interrupt.
> > (2) uhci is generated interrupts when it should not.
> >
> > It's unlikely that we can do anything about (1), so I was
On Fri, Feb 13, 2015 at 08:01:55PM +, Michael van Elst wrote:
> jo...@britannica.bec.de (Joerg Sonnenberger) writes:
>
> >... As such I find disabling COMPAT_FREEBSD by default a very good
> >idea for increasing the visibility of the problem.
>
> Disabling it by de
On Fri, Feb 13, 2015 at 08:56:12AM -0500, Thor Lancelot Simon wrote:
> But it looks like Tom's still getting the interrupt, which means, at least,
> that he's paying the overhead of a quick "Nope, no handler for this one!"
> return from the interrupt handling code. How far upstream is it possible
On Fri, Feb 13, 2015 at 09:26:48AM -0500, Greg Troxel wrote:
>
> Maxime Villard writes:
>
> > Apparently, compat-FreeBSD is needed by tw_cli users.
> >
> > Therefore I think I will just disable it by default in the GENERIC kernels,
> > unless anyone disagrees.
>
> Our norms for significant chan
On Thu, Feb 12, 2015 at 09:02:37PM -0500, Thor Lancelot Simon wrote:
> On Thu, Feb 12, 2015 at 07:52:10PM +0100, Tom Ivar Helbekkmo wrote:
> > Tom Ivar Helbekkmo writes:
> >
> > > The uhci pins on the ioapics are chalking up a few interrupts, but not
> > > many, and no bursts.
> >
> > Still noth
On Thu, Feb 12, 2015 at 09:36:52AM +0100, Joerg Sonnenberger wrote:
> Well, let's try the first hack of keep uhci interrupts off and just poll
> via timeout.
Let's not forget the second part in the header ;)
Joe
On Thu, Feb 12, 2015 at 05:02:28AM +0100, Tom Ivar Helbekkmo wrote:
> Joerg Sonnenberger writes:
>
> > Can you add a counter to uhci.c line 1317? The question for me is
> > whether the device is creating interrupts without actually setting the
> > status to anything
On Wed, Feb 11, 2015 at 07:52:11PM +0100, Tom Ivar Helbekkmo wrote:
> Now, here're some counters during a hang. It was a three second hang,
> and a "vmstat -i 10" that was running jumped the count by about 14000 on
> uhci2, and 13000 on uhci0, during the period where the hang was
> exhibited. In
On Thu, Nov 13, 2014 at 01:59:09PM -0600, David Young wrote:
> On Thu, Nov 13, 2014 at 12:41:38PM +0900, Kengo NAKAHARA wrote:
> > (2014/11/13 11:54), David Young wrote:
> > >On Fri, Nov 07, 2014 at 04:41:55PM +0900, Kengo NAKAHARA wrote:
> > >>Could you comment the specification and implementation
On Mon, Nov 10, 2014 at 06:06:54PM +, Andrew Cagney wrote:
> On 9 November 2014 17:12, Joerg Sonnenberger wrote:
> >> >> o .eh_frame in kernel is not used yet, and safely removed from /netbsd
> >> >
> >> > Please do not.
> >>
> >> o
On Mon, Nov 10, 2014 at 01:40:59AM +0900, Masao Uebayashi wrote:
> On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger
> 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]
> >
&g
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.
> o .eh_frame is generated by GCC/LLVM [2]
Yes.
> o Some code under src/sys/ reference it, but not finished & hooked to any
> kernel functionality (ddb(4)?)
Yes.
Hi all,
please review the attached patch to remove the two remaining MI uses of
random(9). Neither should be in a performance critical code path and
both may actually benefit from the better distribution. The vfs_bio.c
change is a bit more involved as I am trying to replace a 32bit division
with a
On Mon, Aug 25, 2014 at 09:09:24PM +, Taylor R Campbell wrote:
>Date: Mon, 25 Aug 2014 20:02:44 +0200
>From: "J. Hannken-Illjes"
>
>Short answer: it is -- reverting external/gpl3/gcc/dist/gcc/builtins.c
>from Rev. 1.3 to 1.2 brings back the old times which are the same as
>
Hi all,
attached is a first step toward a new handling of the symbol table
embedding. The patch currently always links the kernel twice, but I plan
to refine it in a second step, so that size of the first step is
estimated based on either the default kernel or the last round and to
skip the relink
Hi all,
while working on the sysctl conversion, I found myself wondering whether
it is useful to add a syctl interface for the old interrupt count or
just request that all ports are finally converted to evcnt(9).
The list of ports still declaring intrcnt is:
arm: acorn32, epoc32, hpcarm, shark
m6
On Thu, May 15, 2014 at 10:06:18PM +, David Holland wrote:
> On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
> > Modified Files:
> >src/sys/ufs/ufs: inode.h
> >
> > Log Message:
> > Make filehandles on UFS based filesystems use proper 64bit inodes.
> > 32bit restrict
On Wed, May 14, 2014 at 04:40:03PM -0400, Christos Zoulas wrote:
> Should we fix them?
Some of them are 3rd party sources, I would strongly prefer to keep
those pristine.
Joerg
On Tue, May 06, 2014 at 09:52:53PM +0200, Matthias Drochner wrote:
>
> On Tue, 6 May 2014 21:27:27 +0200
> Joerg Sonnenberger wrote:
> > > While I don't think that it causes these problems, an obvious
> > > deficiency is that our kernel semaphores get inherited
On Tue, May 06, 2014 at 08:20:29PM +0200, Matthias Drochner wrote:
>
> On Tue, 6 May 2014 19:43:24 +0200
> Joerg Sonnenberger wrote:
> > > As has been mentioned before, the (kernel) semaphore implementation
> > > in -current doesn't work well.
> >
>
On Tue, May 06, 2014 at 07:34:44PM +0200, Matthias Drochner wrote:
>
> On Tue, 6 May 2014 10:51:43 -0400
> Matthew Mondor wrote:
> > I have the impression that those syscalls should all be documented in
> > a section 2 manual page instead (kern/37427).
>
> As has been mentioned before, the (kern
On Wed, Apr 23, 2014 at 09:16:33AM -0400, Thor Lancelot Simon wrote:
> On Wed, Apr 23, 2014 at 10:57:59AM +0200, Joerg Sonnenberger wrote:
> > On Tue, Apr 22, 2014 at 11:59:38PM -0400, Thor Lancelot Simon wrote:
> > > I believe ChaCha8 is suitable for our purpose:
On Tue, Apr 22, 2014 at 11:59:38PM -0400, Thor Lancelot Simon wrote:
> I believe ChaCha8 is suitable for our purpose: we were previously considering
> ciphers with, at most, 128-bit security, and even 6-round ChaCha has 139-bit
> strength against the best currently known attack (at present, there i
On Fri, Apr 18, 2014 at 05:05:37PM -0400, Thor Lancelot Simon wrote:
> On Fri, Apr 18, 2014 at 05:00:50PM -0400, Thor Lancelot Simon wrote:
> >
> > Unfortunately, the virtual machines on this laptop that I use for most
> > NetBSD development don't expose the AES-NI instructions to guests, even
> >
On Fri, Mar 14, 2014 at 09:51:12AM -0400, Christos Zoulas wrote:
> I don't think that putting ptmx inside devpts makes sense. OTOH, we
> could have multiple ptmx devices with different minor numbers and use that
> as the differentiating factor for the pty devices. I think that's too complex
> and p
On Tue, Feb 18, 2014 at 12:54:05PM +0100, Yann Sionneau wrote:
> Is there somewhere a function like vaddr_t map_paddr(paddr_t, prot)?
uvm_km_alloc with UVM_KMF_VAONLY can be used to allocate the VA,
pmap_kenter_pa to map a given physical address. Don't forget to call
pmap_update(pmap_kernel()) aft
On Fri, Feb 07, 2014 at 06:28:59PM +, David Holland wrote:
>
> (1) It seems the consensus over the last 5+ years is that the library
> we want is a data transfer library, not a data storage library. If you
> want the latter, we have libdb and sqlite.
Agreed, but please avoid db(3) :)
> (2) W
On Sun, Feb 02, 2014 at 04:43:49PM +0100, Jean-Yves Migeon wrote:
> Even functions like calloc(3) are not required to check for the
> overflow themselves when you pass them (number of elements, sizeof
> elements).
It is required to, otherwise the return value would not be a pointer to
an array of
On Fri, Jan 24, 2014 at 01:19:52PM +, Emmanuel Dreyfus wrote:
> The alternative is to switch the whole userland to amd64 at the same time
> the kernel is changed. It means the new kernel cannot be tested without
> undergoing changes to the system that are difficult to revert. This is
> not good
On Tue, Jan 21, 2014 at 05:33:41PM +, Emmanuel Dreyfus wrote:
> A quick and dirty way to work the problem around is to use the amd64
> binaries for ipf and raidctl. But that cannot work with the rest of
> the system not yet migrated to amd64: amd64 binaries will get the i386
> dyanmic loader /
On Sun, Dec 08, 2013 at 06:21:16PM -0500, Mouse wrote:
> > My irritation with not being able to pass a data pointer through
> > qsort() boiled over just now.
>
> This sort of thing is one reason I do not consider nested function
> support optional in any compiler I consider using: they make it eas
On Sun, Dec 08, 2013 at 10:29:53PM +, David Holland wrote:
> I have done it by having the original, non-_r functions provide a
> thunk for the comparison function, as this is least invasive. If we
> think this is too expensive, an alternative is generating a union of
> function pointers and mak
On Wed, Dec 04, 2013 at 12:04:23PM -0200, Lourival Vieira Neto wrote:
> Hi Mindaugas,
>
> >> Here is a patch that puts ptrdiff_t in the kernel. It also creates a
> >> sys/stddef.h header.
> >
> > Why sys/stddef.h? Just keep them in sys/types.h please.
>
> To avoid redefining ptrdiff_t on stddef.
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 the stack has all the arguments).
Not exactly true. Floating point values are returne
On Thu, Oct 17, 2013 at 08:57:23PM +0900, Izumi Tsutsui wrote:
> Anyway, our commit guidelines explicitly require Core's approval
> before adding a new package into base. You violate the rule.
I didn't.
Joerg
On Thu, Oct 17, 2013 at 09:17:38AM +0200, Martin Husemann wrote:
> But for kernel, I think a better design is needed.
I completely disagree that any of this provides an actual improvement.
Joerg
On Wed, Oct 16, 2013 at 06:00:56PM +0200, Martin Husemann wrote:
> On Wed, Oct 16, 2013 at 05:35:54PM +0200, Joerg Sonnenberger wrote:
> > Look at lib/libc/Makefile?
>
> Ok, I see it is build into libc on some archs with clang, but where is it
> called?
libexecinfo, libc++, o
On Wed, Oct 16, 2013 at 05:22:15PM +0200, Martin Husemann wrote:
> On Wed, Oct 16, 2013 at 05:09:25PM +0200, Joerg Sonnenberger wrote:
> > The need was mentioned a number of times in various threads about libc++
> > and clang.
>
> But for the kernel? And the details?
> Li
On Wed, Oct 16, 2013 at 11:36:18AM +, Martin Husemann wrote:
> On Mon, Oct 14, 2013 at 01:14:58AM +0000, Joerg Sonnenberger wrote:
> > Module Name:src
> > Committed By: joerg
> > Date: Mon Oct 14 01:14:58 UTC 2013
> >
> > Added Fil
On Mon, Oct 07, 2013 at 12:05:26PM +0200, Alan Barrett wrote:
> If the same source code will be compiled into both the kernel and
> userland, then I think that src/common/external//
> would be the place for that.
Let's please not import new sources from 3rd parties into src/common.
src/sys/externa
On Wed, Sep 18, 2013 at 03:51:03PM -0400, Mouse wrote:
> >> Yes, I run 24 concurent tar -czf as a test.
> > But those shouldn't do small synchronous writes, should they?
>
> Depends. Is the filesystem mounted noatime (or read-only)? If not,
> there are going to be atime updates, and don't all in
On Sun, Aug 18, 2013 at 06:04:55PM +0200, Johnny Billquist wrote:
> It's an obvious optimization to keep type already in the directory
> itself. But is there any other reason why it was added there? It
> obviously means you have the same information in two places, with
> all the obvious risks of ha
On Sun, Aug 18, 2013 at 05:36:47PM +0200, Johnny Billquist wrote:
> There is nothing in the directory entry that even tells if the entry
> is a directory or just a plain file, unless I remember wrong. And
> they are not sorted so that all directories comes first...
There is a type tag for each dir
On Sun, Aug 18, 2013 at 03:08:21PM +0200, Manuel Wiesinger wrote:
> My question is:
> Is the number of subdirectories really limited by (2^15)-1?
Yes. A subdirectory creates a hard-link to the parent directory's inode
and nlink counter is 16bit. Whether or not that is interpreted as signed
in all
201 - 300 of 529 matches
Mail list logo
