vfs cache timing changes

Hello, Hi, so I did some timing tests before and after the vfs cache changes. The original run for build.sh -j 80 build.sh started:Wed Sep 11 14:00:09 EDT 2019 build.sh ended: Wed Sep 11 16:48:03 EDT 2019 2:47:54 Then I just moved name and nlen last and added the

Re: more fexecve questions

In article <20190910195235.gp...@irregular-apocalypse.k.bsd.de>, Christoph Badura wrote: >On Tue, Sep 10, 2019 at 09:45:50PM +0200, Christoph Badura wrote: >> This is to catch the following case(s): The file might have the >> following permissions "--x--x--x" (or equivalent where the open()ing

NCHNAMLEN vnode cache limitation removal

Comments? Thanks, christos Index: sys/namei.h === RCS file: /cvsroot/src/sys/sys/namei.h,v retrieving revision 1.98 diff -u -p -u -r1.98 namei.h --- sys/namei.h 3 Jun 2019 06:05:39 - 1.98 +++ sys/namei.h 10 Sep 2019

Re: more fexecve questions

In article <20190910162429.a525e60...@jupiter.mumble.net>, Taylor R Campbell wrote: >> >> I guess we could, since the problem is that if the filename is greater than >> NCHNAMLEN, they will not be cached. But I am not familiar enough with the >> cache to make the changes required. > >I don't

Re: more fexecve questions

In article <20190910150418.becab60...@jupiter.mumble.net>, Taylor R Campbell wrote: >> Date: Tue, 10 Sep 2019 10:52:47 -0400 >> From: chris...@zoulas.com (Christos Zoulas) >> >> 1. Looks like FreeBSD (and my initial posting) leaves the file descripto

more fexecve questions

1. Looks like FreeBSD (and my initial posting) leaves the file descriptor of the executable open in the process's image. The Linux man page says to set close-on-exec if you don't want it to be passed to the child process. Which behavior do you prefer? To have fexecve close the fd

Re: fexecve

In article <20190908183938.ga25...@panix.com>, Thor Lancelot Simon wrote: >On Sun, Sep 08, 2019 at 06:27:11PM -, Christos Zoulas wrote: >> In article <20190908180303.ga6...@panix.com>, >> Thor Lancelot Simon wrote: >> >On Sun, Sep 08, 2019 at 01:

Re: fexecve

In article <20190908180303.ga6...@panix.com>, Thor Lancelot Simon wrote: >On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: >> >> Here's a simple fexecve(2) implementation. Comments? > >I think this is dangerous in systems which use chroot into

fexecve

Here's a simple fexecve(2) implementation. Comments? christos Index: include/unistd.h === RCS file: /cvsroot/src/include/unistd.h,v retrieving revision 1.151 diff -u -p -u -r1.151 unistd.h --- include/unistd.h18 Nov 2018

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

In article <19705.1561931...@splode.eterna.com.au>, matthew green wrote: >i fully support making debugging work. that means debugging >32 bit apps on 64 it kernels, and also, eventually?, using >a 32 bit debugger on 64 bit kernel. > >these are all real-world cases people use and expect to work.

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

In article , Michael van Elst wrote: >chris...@astron.com (Christos Zoulas) writes: > >>We can fill them completely with 0 as we pad with 0 the 32 bit >>part of the 64 bit registers that does not exist in a 32 bit >>process. > >The corefile pretends to be a 32bit

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

In article , Michael van Elst wrote: >m...@eterna.com.au (matthew green) writes: > >>i fully support making debugging work. that means debugging >>32 bit apps on 64 it kernels, and also, eventually?, using >>a 32 bit debugger on 64 bit kernel. > >Can we prevent a 64bit kernel to dump 64bit

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

I think that our goal is be able to branch 9 with a gdb that works as well as 7 (since it is more broken in 8 because of the 64->32 breakage). christos

Re: re-enabling debugging of 32 bit processes with 64 bit debugger

In article , Andrew Cagney wrote: > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it >can't handle an exec() call where the new executable has a different >ISA; and this imnsho is a must have. It is really hard to make a 32 bit debugger work on a 64 bit system because of

re-enabling debugging of 32 bit processes with 64 bit debugger

ing) Best, christos Christos Zoulas wrote: >In article , >Maxime Villard wrote: >> >>This isn't correct, with USER_LDT the 32bit LWPs may have non-default segregs, >>besides it is really dumb to mix 32 and 64bit code, part of the reasons why >>I dropped the thi

Re: [clang-format] [NetBSD Style] Clarification regarding Include files order in NetBSD

On Jun 11, 3:27pm, dholland-t...@netbsd.org (David Holland) wrote: -- Subject: Re: [clang-format] [NetBSD Style] Clarification regarding Include | On Tue, Jun 11, 2019 at 07:49:33PM +0530, Manikishan Ghantasala wrote: | > After discussing with my mentors @christos, @mgorny and some devs in | >

Re: [PATCH v3 2/2] Implement PT_GETXSTATE and PT_SETXSTATE

LGTM. Many thanks, christos > On Jun 7, 2019, at 2:33 PM, Michał Górny wrote: > > if (kl < 0)

Re: [PATCH v2 2/2] Implement PT_GETXSTATE and PT_SETXSTATE

In article <62b4f30a-f5ad-6e6c-1406-568e5d517...@gmx.com>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 06.06.2019 17:10, Christos Zoulas wrote: >> It is better style to do avoid the extra checks and duplication so I would >> also fix the origin

Re: [PATCH v2 2/2] Implement PT_GETXSTATE and PT_SETXSTATE

On Jun 6, 4:43pm, mgo...@gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) wrote: -- Subject: Re: [PATCH v2 2/2] Implement PT_GETXSTATE and PT_SETXSTATE | I presume you mean the one in ptrace_machdep_dorequest()? I suppose it | was there (the code is based on xmmregs in i386) to clearly scope |

Re: [PATCH v2 2/2] Implement PT_GETXSTATE and PT_SETXSTATE

On Jun 5, 5:08pm, mgo...@gentoo.org (=?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=) wrote: -- Subject: [PATCH v2 2/2] Implement PT_GETXSTATE and PT_SETXSTATE | Introduce two new ptrace() requests: PT_GETXSTATE and PT_SETXSTATE, | that provide access to the extended (and extensible) set of FPU |

Re: [PATCH v2 1/2] compat32: translate userland PT_* request values into kernel

On May 30, 7:29pm, mgo...@gentoo.org (=?UTF-8?q?Micha=C5=82=20G=C3=B3rny?=) wrote: -- Subject: [PATCH v2 1/2] compat32: translate userland PT_* request values i | Currently, the compat32 passes PT_* request values to kernel functions | without translation. This works fine for low PT_* requests

Re: svr4, again

Let's retire them. christos > On Mar 9, 2019, at 5:28 AM, Maxime Villard wrote: > > Re-reading this thread - which was initially about SVR4 but which diverged in > all directions -, I see there were talks about retiring COMPAT_ULTRIX and > COMPAT_OSF1, because these were of questionable

re: aprint_* used outside autoconfiguration step

On Feb 20, 8:44am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: aprint_* used outside autoconfiguration step | i don't like that patch for two reasons: | | - if config_pending must be exposed, do it properly, not with a | another extern that isn't seen by the definition.

Re: aprint_* used outside autoconfiguration step

On Feb 19, 10:19am, buh...@nfbcal.org (Brian Buhrow) wrote: -- Subject: Re: aprint_* used outside autoconfiguration step | hello. Is it sufficient to do something like: | | if (cold) { | aprint_error("..."); | } else { | printf("..."); | } | | or, is that what your new

Re: aprint_* used outside autoconfiguration step

On Feb 19, 9:39am, buh...@nfbcal.org (Brian Buhrow) wrote: -- Subject: Re: aprint_* used outside autoconfiguration step | Hello. I'm a little confused by the goal of this change? If there | are are errors worth printing messages about, shouldn't the author of the | error message have a

aprint_* used outside autoconfiguration step

Hi, I've noticed that now the "autoconfiguration print" error messages are printing "autoconfiguration error: " we have a situation where aprint_ calls are happening outside the autoconfiguration process. This is confusing. What makes this difficult to fix is: 1. Some of the calls can

Re: fallthrough and breaks in drm and atheros codes

Yes, the order matters. I am not sure why it is different in my build... christos > On Feb 18, 2019, at 8:40 PM, Robert Elz wrote: > >Date:Mon, 18 Feb 2019 19:26:07 -0500 >From: Christos Zoulas >Message-ID: > > > | there is -Wno-er

Re: fallthrough and breaks in drm and atheros codes

> On Feb 18, 2019, at 7:20 PM, matthew green wrote: > >> I am not sure if the following is correct, so I am posting it here instead >> of committing... > > see my post to source-changes-d -- most of these should > be ignored for warings already, so i'm curious why you > had to fix them. > >

fallthrough and breaks in drm and atheros codes

Hi, I am not sure if the following is correct, so I am posting it here instead of committing... christos Index: external/bsd/drm2/dist/drm/nouveau/nvkm/engine/dma/nouveau_nvkm_engine_dma_usernv04.c === RCS file:

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

In article , Rin Okuyama wrote: >Hi, > >On 2019/02/13 6:07, Paul Goyette wrote: >> On Tue, 12 Feb 2019, Rin Okuyama wrote: >> >>> Hi, >>> >>> As Martin pointed out, it is useful for debugging to turn on >>> DIAGNOSTIC for modules (for non-release branches). >>> >>> Now, all modules for amd64

Re: kernel frameworks for jumbo frame

In article <20190130110317.gc28...@mail.duskware.de>, Martin Husemann wrote: >On Wed, Jan 30, 2019 at 07:59:13PM +0900, Rin Okuyama wrote: >> I think we agree to add API something like >> >> On 2019/01/29 17:32, Maxime Villard wrote: >> > int >> > m_addjcl(struct mbuf *m, int how, int

Re: patch: debug instrumentation for dev/raidframe/rf_netbsdkintf.c

In article <20190122173641.ga26...@irregular-apocalypse.k.bsd.de>, Christoph Badura wrote: >On Mon, Jan 21, 2019 at 11:44:04PM +0100, Christoph Badura wrote: >> On Tue, Jan 22, 2019 at 08:32:48AM +1100, matthew green wrote: >> > > > @@ -472,6 +472,9 @@ >> > > >const char *bootname =

Re: patch: debug instrumentation for dev/raidframe/rf_netbsdkintf.c

In article <24279.1548106...@splode.eterna.com.au>, matthew green wrote: >> > @@ -472,6 +472,9 @@ >> >const char *bootname = device_xname(bdv); >> >size_t len = strlen(bootname); >> > >> > + if (bdv == NULL) >> > + return 0; >> > + >> >> This looked suspicious, even before I

re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

On Jan 7, 8:46am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys | > http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt | | for xhci, all of these seem to be the same issue and it | appears to be a "high level

Re: Adding new feature - Kcov

In article , Siddharth Muralee wrote: >On Thu, 3 Jan 2019 at 22:39, Christos Zoulas wrote: >> >> In article >, >> Siddharth Muralee wrote: >> >On Wed, 2 Jan 2019 at 23:12, Christos Zoulas wrote: >> >> >>

Re: Adding new feature - Kcov

In article , Siddharth Muralee wrote: >On Wed, 2 Jan 2019 at 23:12, Christos Zoulas wrote: >> >> In article >, >> Siddharth Muralee wrote: >> >-=-=-=-=-=- >> > >> >On Wed, 2 Jan 2019 at 09:26, Siddharth Muralee >> >wrote: >&g

Re: Adding new feature - Kcov

In article , Siddharth Muralee wrote: >-=-=-=-=-=- > >On Wed, 2 Jan 2019 at 09:26, Siddharth Muralee >wrote: >> >> Hello, I have attached a modified patch for kcov(4). I have modified >> it to be a per-process lookup instead of the earlier per-unit lookup. >> >> It seems to working fine. I have

Re: scsipi: physio split the request

On Dec 27, 12:29pm, buh...@nfbcal.org (Brian Buhrow) wrote: -- Subject: Re: scsipi: physio split the request | hello. Just out of curiosity, why did the tls-maxphys branch never | get merged with head once the work was done or mostly done? mostly done... christos

Re: scsipi: physio split the request

In article <20181227153028.gr4...@homeworld.netbsd.org>, Emmanuel Dreyfus wrote: >On Thu, Dec 27, 2018 at 09:47:03AM -0500, Christos Zoulas wrote: >> | What happens if I just #define MAXPHYS (1024*1204*1024) ? >> I don't think that's a good idea. My guess is that things

Re: scsipi: physio split the request

On Dec 27, 2:41pm, m...@netbsd.org (Emmanuel Dreyfus) wrote: -- Subject: Re: scsipi: physio split the request | On Thu, Dec 27, 2018 at 02:33:28PM +, Christos Zoulas wrote: | > I think you need resurrect the tls-maxphys branch... It was close to working | > IIRC. | | What happens if

Re: scsipi: physio split the request

In article <20181227123711.go4...@homeworld.netbsd.org>, Emmanuel Dreyfus wrote: >On Thu, Dec 27, 2018 at 10:44:46AM +0100, Manuel Bouyer wrote: >> tape block size are usually larger than 512 (I use 64k here). >> What block size did mkltfs use ? Actually we can't do larger than 64k. > >It seems

Re: Current best practice for testing a new kernel API?

On Dec 23, 10:04am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: Current best practice for testing a new kernel API? | A downside I see to the rump option... as far as I can tell, rumpkern is bu= | ild with no DIAGNOSTIC, so all of the KASSERT()s in kern_threadpool.c will = | never get a

Re: Current best practice for testing a new kernel API?

On Dec 23, 9:04am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: Current best practice for testing a new kernel API? | > Some ideas: | > - kernel module to load the test | > - use rump | | It's almost noon where you are, Christos, but I'm not sure you've had your = | coffee yet

Re: Current best practice for testing a new kernel API?

In article <969df6c3-996d-45ff-8414-969470006...@me.com>, Jason Thorpe wrote: >Howdy folks -- > >I'm currently working on whipping riastradh@'s threadpool / taskqueue >draft implementations into shape. I wrote a simple test jig that lets >me exercise the threadpool API from user space, in

Re: svr4, again

In article <3af3b7c6-d34e-471d-8cf8-a411e9032...@me.com>, Jason Thorpe wrote: >While I agree that it’s not exactly difficult to maintain the a.out >exec package, I do wonder if there is anyone out there actually running >ancient a.out binaries. Well, I still have a lisp from 0.9 :-) Anyway if

Re: svr4, again

In article , Jaromír DoleÄ ek wrote: >Le mar. 18 déc. 2018 à 13:16, Maxime Villard a écrit : >> It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the >> use of the code: > >+1 to removal for COMPAT_SVR4, there is always attic. > >I remember I've been also doing some

Re: Question about memory

In article , Prowell, Stacy J. wrote: >I have a question about memory, and hope this is the place to ask. > >I have blades that have 1.5TB of DRAM, and want to run NetBSD if I can, >but I am hitting the 512GB limit. “panic: RAM limit reached: > 512GB >not supported” > >Can someone give me a

Re: svr4, again

In article <7fd8e657-dafb-1efc-0a23-762803589...@m00nbsd.net>, Maxime Villard wrote: >Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding >bugs, and it's becoming tiring. Over time I've come across at least a good >dozen of bugs in it, by just grepping through the tree

Re: enhance sysctl kern.expose_address

On Dec 5, 8:45am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: enhance sysctl kern.expose_address | ...also it looks like the kauth callback doesn't handle the "2" case of | "everyone can see". It does, by not break'ing... | Also, I think the sysctl should validate that the value

Re: enhance sysctl kern.expose_address

On Dec 5, 8:47am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: enhance sysctl kern.expose_address | Also, should PK_KMEM be inherited across fork? What if a process opens | /dev/kmem, and then forks/execs a helper to do the work, passing the file | descriptor along with it?

Re: enhance sysctl kern.expose_address

On Dec 5, 8:38am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: enhance sysctl kern.expose_address | PK_KMEM should only be set if mm_open returns 0. There's a case where | mm_md_open can return an error and PK_KMEM is still set. Thanks, christos Index: mm.c

enhance sysctl kern.expose_address

This patch: https://www.netbsd.org/~christos/kmem_expose_address.diff Changes kern.expose_address to a tri-state variable: 0: no access 1: access only to processes that have opened /dev/kmem 2: access to every process It also optimizes the access control to happen only once per sysctl (not

Re: noatime mounts inhibiting atime updates via utime()

In article <1543941318.804.8.ca...@gentoo.org>, MichaŠGórny wrote: >-=-=-=-=-=- > >Hello, > >Today me and Kamil noticed some more LLVM tests failing due to the host >filesystem being mounted with 'noatime' option. Upon closer >investigation, it turned out that on NetBSD noatime inhibits not

Re: fixing coda in -current

In article <20181120183715.ga11...@homeworld.netbsd.org>, wrote: >On Tue, Nov 20, 2018 at 08:25:38PM +1030, Brett Lymn wrote: >> >> Comments? Anyone really care? > >IMO - your call (or christos's). You two have done more than enough for >the rest of us that we can tolerate some work if you like

Re: fixing coda in -current

In article , Maxime Villard wrote: >Le 20/11/2018 à 16:18, Greg Troxel a écrit : >> I used to use it, and may again. So I'd like to see it stay, partly >> because I think it's good to keep NetBS relevant in the fileystem >> research world. I am expecting to see new upstream activity. > >The

Re: Things not referenced in kernel configs, but mentioned in files.*

In article , Greg Troxel wrote: > >co...@sdf.org writes: > >> This is an automatically generated list with some hand touchups, feel >> free to do whatever with it. I only generated the output. >> >> ac100ic >> acemidi >> acpipmtr >> [snip] > >I wonder if these are candidates to add to an ALL

Re: Reboot resistant USB bug

In article <20181016122719.gi16...@homeworld.netbsd.org>, Emmanuel Dreyfus wrote: >On Thu, Oct 11, 2018 at 02:11:22PM +, Emmanuel Dreyfus wrote: >> On both netbsd-8 and -current, I have a problem with USB devices that >> get stuck in a non-functionning state even after a reboot. > >I

Re: videoio.h

In article , Robert Swindells wrote: > >I have been adding stuff to sys/videoio.h to get the latest version of >the V4L package to build. > >The Linux headers that contain the equivalent definitions are dual >licenced, OpenBSD has just copied the contents of them into their >version of

Re: Too many PMC implementations

On Aug 23, 11:57am, t...@panix.com (Thor Lancelot Simon) wrote: -- Subject: Re: Too many PMC implementations | On Thu, Aug 23, 2018 at 05:09:35PM +0200, Kamil Rytarowski wrote: | > | > Observing that all the useful profiling is already done with DTrace, we | > can remove complexity from the

Re: kasan: monitor pools

On Aug 21, 2:30pm, m...@m00nbsd.net (Maxime Villard) wrote: -- Subject: Re: kasan: monitor pools | Why not, but origsize will become unused, so still need one ifdef. Yes, I've left the ifdef, instead of __kasanused :-) christos

Re: kasan: monitor pools

On Aug 21, 1:17pm, campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell) wrote: -- Subject: Re: kasan: monitor pools | Make it a static inline with empty body instead of a #define | __nothing? Because i don't want the parameters to have to exist (be declared) or be evaluated... I want them

Re: kasan: monitor pools

In article <2a4c7cde-ab5e-68b7-de0f-0a307e91a...@m00nbsd.net>, Maxime Villard wrote: >Here is a patch [1] that allows kasan to monitor pools and pool_caches. We >recycle the existing POOL_REDZONE implementation - which I wrote three years >ago, and which has never been enabled (not even on

Re: New getsockopt2() syscall

Commit it then? christos > On Jul 30, 2018, at 3:42 AM, Robert Swindells wrote: > > > chris...@zoulas.com (Christos Zoulas) wrote: >> On Jun 24, 11:18pm, r...@fdy2.co.uk (Robert Swindells) wrote: >> -- Subject: Re: New getsockopt2() syscall >> &g

Re: aarch64 gcc kernel compilation

On Jul 17, 10:39am, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: aarch64 gcc kernel compilation | I was thinking about this one: | | http://netbsd.org/~kamil/patch-00067-conditional-u128.txt | | It should do the trick for everybody - including rumpkernel users - and | support aarch64

aarch64 gcc kernel compilation

Hi, Gcc is now working on aarch64 but the kernel does not compile because of some idiomatic clang code that is not supported by gcc (at least gcc-6) To define constants, it uses: static const uintmax_t FOO = __BIT(9), BAR = FOO; While this is nice, specially for the debugger, it produces an

Re: CVS commit: src/sys/arch/x86/x86

In article <20180709145848.ga21...@panix.com>, Thor Lancelot Simon wrote: >On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >> "requirements".

Re: new errno ?

In article <201807061021.35171.p...@netbsd.org>, Phil Nelson wrote: >Hello, > >In working on the 802.11 refresh, I ran into a new errno code from FreeBSD: > >#define EDOOFUS 88 /* Programming error */ > >Shall we add this one? (Most likely with a different number

Re: CVS commit: src/sys/kern

In article <8998.1530490...@splode.eterna.com.au>, matthew green wrote: >Jason Thorpe writes: >> >> >> > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote: >> > >> > I'd rather not have this at all - instead just drop the useless timestamps >> > at boot time, they are useless here and make

Re: New getsockopt2() syscall

On Jun 24, 11:18pm, r...@fdy2.co.uk (Robert Swindells) wrote: -- Subject: Re: New getsockopt2() syscall How about merging them thusly? christos Index: uipc_syscalls.c === RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v retrieving

Re: New getsockopt2() syscall

In article , Robert Swindells wrote: > >chris...@zoulas.com (Christos Zoulas) wrote: >>On Jun 9, 2:20pm, r...@fdy2.co.uk (Robert Swindells) wrote: >>-- Subject: Re: New getsockopt2() syscall >> >>| What is the best way to provide it for review, diffs or the compl

Re: New getsockopt2() syscall

On Jun 9, 2:20pm, r...@fdy2.co.uk (Robert Swindells) wrote: -- Subject: Re: New getsockopt2() syscall | What is the best way to provide it for review, diffs or the complete | page ? Either way. I think that the complete man page is not too long (I just looked). christos

Re: New getsockopt2() syscall

In article , Robert Swindells wrote: > >Are there any objections to the code for a getsockopt2() syscall >in: > > Let's write the man page to see if it makes sense :-) christos

Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled

In article <13557.1527729...@jinx.noi.kre.to>, Robert Elz wrote: >Date:Wed, 30 May 2018 11:39:50 + (UTC) >From:chris...@astron.com (Christos Zoulas) >Message-ID: > > | Looks like a bug to me; it overflows 32 bits. Try changing

Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled

In article , Harry Pantazis wrote: >-=-=-=-=-=- > >Sorry, I faultily sent before completing the mail. > >Continuing.. > >This first errors are located in >src/sys/external/bsd/drm2/dist/drm/i915/intel_ddi.c and are specific >to the switch statement concerning that the case flags are not

Re: FIOSETOWN and TIOCSPGRP vs control ttys

In article <201805172011.qaa05...@stone.rodents-montreal.org>, Mouse wrote: >In sys/kern/tty.c, I find > > case FIOSETOWN: { /* set pgrp of tty */ >[...] > if (tp->t_session != NULL && !isctty(p, tp)) { >

Re: gc private 802.11 rateset declarations

In article <20180429211044.gb18...@sdf.org>, wrote: >-=-=-=-=-=- > >OK to commit this? I don't have any of the devices unfortunately. go for it. christos

Re: e_trapsignal removal

In article <19a85912-f444-6d2d-d09c-427843307...@gmx.com>, Kamil Rytarowski <n...@gmx.com> wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 27.04.2018 21:11, Christos Zoulas wrote: >> In article <b80b33fb-de4f-01dd-1705-716a2c0ec...@gmx.com>, >&

Re: e_trapsignal removal

In article , Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >I propose to remove e_trapsignal from the compat framework > >Rationale: > - It's currently unused. It was used for Darwin compat. > - It's certainly broken and not used

Re: Is there a current known getrusage() problem (amd64)

On Apr 6, 1:59am, k...@munnari.oz.au (Robert Elz) wrote: -- Subject: Re: Is there a current known getrusage() problem (amd64) | Date:Thu, 5 Apr 2018 16:57:31 + (UTC) | From:chris...@astron.com (Christos Zoulas) | Message-ID: <pa5khr$163$1...@blaine.gmane.

Re: Is there a current known getrusage() problem (amd64)

In article <9363.1522926...@jinx.noi.kre.to>, Robert Elz wrote: >Date:Wed, 4 Apr 2018 17:05:51 -0400 (EDT) >From:Mouse >Message-ID: <201804042105.raa04...@stone.rodents-montreal.org> > > | >> Hmm...have you tried

Re: mmap implementation advice needed.

In article <1ce8eac5-3639-aec1-0e0c-fe857f49b...@ludd.ltu.se>, Anders Magnusson wrote: >Hi tech-kern, > >I'm trying to solve PR#28379 and ran into a problem and I don't really >understand how it is supposed to work: >If a process tries to mmap for example a file with a length

Re: compat code function pointers

On Mar 19, 5:55pm, dholland-t...@netbsd.org (David Holland) wrote: -- Subject: Re: compat code function pointers | On Mon, Mar 19, 2018 at 08:35:11AM -0400, Christos Zoulas wrote: | > That's a good idea, but it is more complicated that what we do now, and does | > not solve the p

Re: compat code function pointers

On Mar 19, 10:06am, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: compat code function pointers | On Sun, Mar 18, 2018 at 09:00:06PM -0400, Christos Zoulas wrote: | > The question came up where to store the function pointers for device | > drivers that are not always p

compat code function pointers

Hi, Paul and I have been working towards separating the compat code from the main kernel and eliminating all the COMPAT_XX ifdefs. This will allow the compat modules to work properly even if the kernel is not compiled with the compat options. The general approach to this is to move all the

Re: Port FreeBSD's updated Atheros WiFi Driver

In article <7bf8eb67-bd81-6288-813a-313ea9db5...@gmail.com>, Aditya Upadhyay wrote: >Hi tech-kern, > > >This is Aditya Upadhyay. I was a GSoC student last year at RTEMS >Organization. My Project was POSIX Compliance. This year, I am mentoring >for RTEMS itself. > >I am

Re: KASSERT in exec_elf.c for DYN executable when p_align==0

On Mar 18, 8:15am, al...@yandex.ru (Alexander Nasonov) wrote: -- Subject: Re: KASSERT in exec_elf.c for DYN executable when p_align==0 | Christos Zoulas wrote: | > In article <20180317225722.GA1538@neva>, | > Alexander Nasonov <al...@yandex.ru> wrote: | > >Coverity (CID

Re: KASSERT in exec_elf.c for DYN executable when p_align==0

In article <20180317225722.GA1538@neva>, Alexander Nasonov wrote: >Coverity (CID 1427746) complains about a division by zero when >align is 0 in all PT_LOAD headers. > >I tried reproducing the problem but the code in question is inside >'if (offset < epp->ep_vm_minaddr)' and it

Re: Regarding GSoC

In article

Re: compat work.

On Mar 15, 6:41pm, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: compat work. | Yeah, it was a bit trickier than just resolving the few conflicts that | CVS found, but not as difficult as I'd feared. Yes, there is only non compat code in uvm_swap.c (except the lines that declare the

Re: compat work.

On Mar 15, 10:57am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: compat work. [leaving an ifdef to identify compat only code that can be removed] | That might be useful. I agree. | My goal was to ensure that compat code can be reached, whether it was | built-in to the kernel with

Re: compat work.

On Mar 15, 10:11am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: compat work. | (Adding tech-kern@ to cc) | | Such "factoring out" is far beyond my capabilities, especially when we | get into areas such as the networking code. There are just too many | parts of the system which I

Re: sysctl_doeproc() race

In article , Kamil Rytarowski wrote: >I've been observing a race with the ptrace(2) ATF tests. > >There is a function await_zombie() that checks whether a process (traced >by a debugger) died and is now a zombie. The current

Re: Enabling SVS by default

In article <79261937-8dc1-aeb6-ebd4-c4dcb4027...@m00nbsd.net>, Maxime Villard wrote: >Le 23/02/2018 à 10:45, Edgar Fuß a écrit : >> MV> A sysctl is now available, machdep.svs_enabled >> EF> Why svs_enabled and not simply svs? >> MV> Because that's the common naming

re: setting DDB_COMMANDONENTER="bt" by default

On Feb 17, 9:13am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: setting DDB_COMMANDONENTER="bt" by default | > also the backtrace is not that useful on the default glass console tty | > unless you also limit the number of backtrace level with the new sysctl | > variable I recently

Re: setting DDB_COMMANDONENTER="bt" by default

In article , Sevan Janiyan wrote: > > >On 02/15/18 01:23, Valery Ushakov wrote: >> As someone has already mentioned upthread, because printing a >> backtrace might cause another panic, so the default was selected to be

Re: setting DDB_COMMANDONENTER="bt" by default

In article , Sevan Janiyan wrote: >Hello, >Is there any reason good reason why we should not opt for >DDB_COMMANDONENTER="bt" by default across the board?? >We have it set or a variation of, on some ports (amd64, some

Re: Race condition between an LWP migration and curlwp_bind

In article , Ryota Ozaki wrote: > >Is the fix appropriate? Looks right to me, but it is above my pay grade :-) christos

Re: T_TRCTRAP handling

In article , Dimitris Karagkasidis wrote: >On 02/07/2018 11:14 AM, Martin Husemann wrote: > > QEMU should never let the kernel see any exceptions or other traces of being > > debugged, IMHO. > > > > To me this sounds like a

Re: /dev/ksyms permissions

In article , Maxime Villard wrote: >Le 18/01/2018 à 13:43, Tom Ivar Helbekkmo a écrit : >> Maxime Villard writes: >> >>> Well, looking at the code, it seems to me that _kvm_open() should be >>> changed to

Re: Attempt to fix nfs client

In article <20180120144510.ga61...@atom.tmux.org>, Tobias Ulmer wrote: >TLDR: nfs_reqq crrptin, see diff below. > >I've been trying to track down the source of NFS client hangs and >crashes over the last weeks, in order to get back to the things I really >wanted to do... > >No

<    1   2   3   4   5   6   7   8   >