Re: RFC: New userspace fetch/store API

> On Feb 23, 2019, at 6:35 PM, Robert Elz wrote: > > fuword/fuiword/suword/suiword (etc) are all ancient, and I would > have expected, largely deprecated these days - but what's wrong > with copyin/copyout ?Those could be optimised for particular > data sizes if there was some real need fo

Re: RFC: New userspace fetch/store API

> On Feb 23, 2019, at 4:19 PM, Jason Thorpe wrote: >> On Feb 23, 2019, at 4:04 PM, matthew green wrote: >> >> i like this. the current API is ... odd. >> >> can you add alignment documentation? eg, if only to say that it >> must support aligned

Re: RFC: New userspace fetch/store API

> On Feb 23, 2019, at 4:04 PM, matthew green wrote: > > i like this. the current API is ... odd. Oh… any thoughts on “have intrsafe or not”? -- thorpej

Re: RFC: New userspace fetch/store API

> On Feb 23, 2019, at 4:04 PM, matthew green wrote: > > i like this. the current API is ... odd. > > can you add alignment documentation? eg, if only to say that it > must support aligned or unaligned accesses for the relevant > datatypes. not sure what we need currently, ie, if unaligned

RFC: New userspace fetch/store API

The existing fetch(9) / store(9) APIs have some problems. Specifically: ==> Their return semantics mean that fuword() cannot disambiguate between an error condition (-1) and a legitimate fetch of -1 from user space. ==> “word” is poorly defined. For all practical purposes, it means “long”, and

Re: aprint_* used outside autoconfiguration step

> On Feb 19, 2019, at 1:44 PM, matthew green wrote: > > can we eliminate this one entirely while we are at it? it's > unfortunately used a *lot*. We should probably just get rid of aprint_naive(), too. > >> 2. We don't have a non-autoconfig-related family of printf >> calls to

Re: EVFILT_USER?

> On Feb 17, 2019, at 3:33 PM, Kamil Rytarowski wrote: > > 1. POSIX robus pthread(3) mutexes > 2. pshared support in pthread(3) Yes. I may or may not be able to look at that in the near future… my first priority will be to convert POSIX semaphores to use futexes. Futexes have the potentia

Re: EVFILT_USER?

> On Feb 17, 2019, at 4:03 PM, Christoph Badura wrote: > > On Sun, Feb 17, 2019 at 01:48:52PM -0800, Jason Thorpe wrote: >>> On Feb 17, 2019, at 1:32 PM, co...@sdf.org wrote: >>> the linux equivalent code seems to be using futex_wait/wake. >> >>

Re: EVFILT_USER?

> On Feb 17, 2019, at 1:32 PM, co...@sdf.org wrote: > > the linux equivalent code seems to be using futex_wait/wake. I’m working on integrating a new Linux-compatible futex implementation written by Taylor (that led me down the rabbit hole of needing to fix issues with fetch(9) / store(9) fi

Re: Support for "pshared" POSIX semaphores

> On Feb 4, 2019, at 6:36 PM, SODA Noriyuki wrote: > >>>>>> On Mon, 4 Feb 2019 12:18:35 -0800, Jason Thorpe said: > > The reason why the SUS definition is so nasty is that it implicitly > assumes pshared semaphore (and pshared mutex) will be implemented &g

Re: Support for "pshared" POSIX semaphores

> On Feb 4, 2019, at 4:30 AM, Joerg Sonnenberger wrote: > > This seems to allow attaching to random semaphores by just knowing the > right idea. This violates the definition of anonymous semaphores and I > wouldn't be surprised if it creates some nasty security issues... Well, the SUS says th

Re: Support for "pshared" POSIX semaphores

> On Feb 1, 2019, at 11:36 PM, Ryo ONODERA wrote: > > Thank you very much! > On NetBSD/amd64-current with your patch, pkgsrc/www/firefox-65.0.1nb1 I just confirmed it works correctly with firefox52 on my Pinebook as well. It still crashed when I attempted to use iCloud.com’s email client, b

Re: Support for "pshared" POSIX semaphores

Ds are random anyway, I didn’t bother with any exotic hash function — just extract some of the random bits to use as the bucket index. I also added some test cases to exercise the basic lifecycle of the ksem objects. I plan to check this in later today. > On Feb 2, 2019, at 11:44 AM, Jason Thor

Re: Support for "pshared" POSIX semaphores

> On Feb 2, 2019, at 10:38 AM, Kamil Rytarowski wrote: > > Are we far away from supporting pshared in pthread.h too? > > There are already function stubs for this in the header hidden with > _PTHREAD_PSHARED. In theory, a bunch of the pthread pshared stuff could be implemented on top of _kse

Re: Support for "pshared" POSIX semaphores

> On Feb 2, 2019, at 11:44 AM, Jason Thorpe wrote: > >> - Why not just add a new syscall, instead of the KSEM_PSHARED stuff? > > Mainly because a new syscall is more intrusive, and harder to back-port. > It’s a shame the existing system call didn’t have a way to pass

Re: Support for "pshared" POSIX semaphores

> On Feb 2, 2019, at 11:11 AM, Martin Husemann wrote: > > On Sat, Feb 02, 2019 at 01:16:47PM -0400, Jared McNeill wrote: >> It might be worth requesting a pull-up to netbsd-8 as well. > > Don't think we can do that (it requires a kernel version bump, doesn't it?) Yes, I change a small bit of

Re: Support for "pshared" POSIX semaphores

> On Feb 2, 2019, at 10:33 AM, Mindaugas Rasiukevicius wrote: > > Jason Thorpe wrote: >> Patch is here: >> https://patch-diff.githubusercontent.com/raw/thorpej/netbsd-src/pull/5.diff > > Thanks for working on this. > > - Why not just add a new syscall,

Re: Support for "pshared" POSIX semaphores

> On Feb 1, 2019, at 11:36 PM, Ryo ONODERA wrote: > > Thank you very much! > On NetBSD/amd64-current with your patch, pkgsrc/www/firefox-65.0.1nb1 > with browser.tabs.remote.autostart=true works fine. Thanks for testing it for me! > However your patch fot sys/kern/uipc_sem.c fails in > nooptio

Support for "pshared" POSIX semaphores

-port-arm +tech-kern > On Jan 24, 2019, at 5:58 AM, Jared McNeill wrote: > > The tab crashes are related to http://gnats.netbsd.org/53273, which can be > worked around by setting the autostart properties to false. The other crashes > are not related, feel free to debug and fix them! I’ve adde

Re: kernel frameworks for jumbo frame

> On Jan 30, 2019, at 3:29 PM, Robert Elz wrote: > > | Yes, I think something like: > | > |size_t mbuf_cluster_size_for_size(size_t desired_size); > > whatever the name, is unlikely to be needed, that would be > used in the "must specify a supportyed size" variant of the > former, rather

Re: kernel frameworks for jumbo frame

> On Jan 30, 2019, at 1:03 PM, 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 size) > > Just a min

Re: kernel frameworks for jumbo frame

> > or > > On 2019/01/29 17:31, Jason Thorpe wrote: >> int mbuf_get_cluster(struct mbuf *m, size_t desired_size); > > I would like to write a draft of patch. Here, how should we treat size > argument; (a) cluster size itself (like FreeBSD), or (b) minimum r

Re: kernel frameworks for jumbo frame

> On Jan 29, 2019, at 10:32 AM, Maxime Villard wrote: > > - As you said, we have only one cluster size to begin with. > - MEXTMALLOC is here to allocate variable-sized clusters, but it is > really ugly and should be removed. Same for MEXTADD. > - The error handling of MCLGET() is error-prone

Re: kernel frameworks for jumbo frame

> On Jan 29, 2019, at 6:57 AM, Rin Okuyama wrote: > > Hi, > > I'm working on jumbo frame support for axen(4) and mue(4). However, > unfortunately, I find that we do not have proper kernel frameworks > for jumbo frame; there are two problems: > > (1) > We do not have external mbuf cluster capa

Re: SIGBUS + coredump

> On Jan 19, 2019, at 8:55 AM, David Holland wrote: > > That's equivalent to writing out zeros (but more efficient) -- I would > say the page shouldn't appear in the dump at all on the grounds that > it doesn't actually exist. > > Whether it's ok to have an empty segment, I dunno. See if gdb

Re: SIGBUS + coredump

> On Jan 18, 2019, at 1:12 AM, Kamil Rytarowski wrote: > >> ISTM that it would better to skip the page than write out zeros... >> > > This behavior is also fine. > > Should it be - in this example - a zero-sized segment? Yes, at the VA where the tail-hole exists, I think you want p_memsz t

Re: SIGBUS + coredump

> On Jan 18, 2019, at 1:03 AM, David Holland wrote: > > On Fri, Jan 18, 2019 at 09:50:38AM +0100, Martin Husemann wrote: >> Sorry, I completely fail to parse this - can you start from scratch and >> just describe the problem you think you are seeing? > > ISTM that it would better to skip the

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

> On Jan 6, 2019, at 2:26 PM, Christos Zoulas wrote: > > Shouldn't the compiler know how to do this right by padding around the > structure that needs alignment and assuming the default alignment for > the enclosing structure? No, because the compiler can't be assured of what alignment the al

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

> On Jan 6, 2019, at 1:46 PM, matthew green wrote: > > ... how do we convey the structure alignment needed for > softc, or do we fix it by moving it into its own separate > aligned allocation? The latter, I think. -- thorpej

Re: pckbc_cd

> On Dec 30, 2018, at 7:59 AM, Kamil Rytarowski wrote: > > On 30.12.2018 16:51, co...@sdf.org wrote: >> Thanks. >> >> I'm not sure if it is a sufficient explanation though, there's a >> CFATTACH_DECL_NEW(pckbc_acpi, ... >> but no >> CFATTACH_DCEL_NEW(pckbc, .. >> >> Or does that work somehow

Re: USB error checking

> On Dec 28, 2018, at 2:26 PM, Terry Moore wrote: > > The man page for bus_dmamap_sync() doesn't say that a length of zero is > forbidden. It certainly was never intended to be forbidden. -- thorpej

"Cross-cancelling" of thread pool jobs

I'm moving this particular part of the threadpool follow-up discussion to tech-kern. > On Dec 26, 2018, at 10:04 AM, Taylor R Campbell > wrote: > >> +bool >> +threadpool_cancel_job_async(threadpool_t *pool, threadpool_job_t *ext_job) >> +{ >> +threadpool_job_impl_t *job = THREADPOOL_JOB_TO

Re: scsipi: physio split the request

> On Dec 27, 2018, at 10:51 AM, Michael van Elst wrote: > > m...@netbsd.org (Emmanuel Dreyfus) writes: > >> What happens if I just #define MAXPHYS (1024*1204*1024) ? > > You need a really huge amount of RAM for that, and also a huge > KVA space. ...but it doesn't have to be that way. The f

threadpool(9) -- an API for scheduling jobs on shared pools of threads

Hey folks ... The other day I checked in a new kernel API - threadpool(9) - an API for scheduling jobs on shared pools of threads. This new API was written by Taylor Campbell, but had been languishing as a WIP draft for some years now. As it happens, I have a need for the (forthcoming, still

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

> On Dec 23, 2018, at 10:04 AM, Jason Thorpe wrote: > > A downside I see to the rump option... as far as I can tell, rumpkern is > build with no DIAGNOSTIC, so all of the KASSERT()s in kern_threadpool.c will > never get a chance to fire. At least the module approach w

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

> On Dec 23, 2018, at 9:34 AM, Martin Husemann wrote: > >> For completeness, I'll explore the rump option > > That is definitively the prefered way. One example is npf usint it to > test custom kernel test code, but that overall is a bit ... complex. A downside I see to the rump option... as

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

> On Dec 23, 2018, at 8:41 AM, Christos Zoulas wrote: > > 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 -- that's essentially what I said in my email. :-) Anyway, one drawback of

Current best practice for testing a new kernel API?

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 isolation (i.e. without depending on any users-of-threadpool), but I'm looking for guida

Re: svr4, again

> On Dec 20, 2018, at 2:36 PM, matthew green wrote: > > netbsd had ELF ports before 1.5. i forget when, but at > least alpha and maybe mips were ELF before i386/sparc's > conversion from a.out in 1.5. Yah, I think Alpha was ECOFF **very briefly**, but went ELF pretty quick. -- thorpej

Re: svr4, again

> On Dec 20, 2018, at 9:34 AM, Terry Moore wrote: > > Nothing as nice as Franz Lisp. Internal little utilities for which we don’t > have source handy and/or we're too lazy to rebuild. I have a (licensed) > version of Unipress Emacs, but I finally gave up and rebuilt that around the > 5.0 tr

Re: svr4, again

> On Dec 20, 2018, at 12:29 PM, Maxime Villard wrote: > So, first things first, and to come back to my email about ibcs2: what are > the reasons for keeping it? As I said previously, this is not for x86 but > for Vax. As was also said, FreeBSD removed it just a few days ago. > > I'm bringing

Re: svr4, again

> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote: > > Kamil Rytarowski 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. >>> >> >> NetBSD 0.9 i386 a.out yes.

Re: svr4, again

5:18:15PM -0800, Jason Thorpe wrote: >>> i would argue that until we're willing to drop a.out exec >>> entirely we should keep the above. let's not chip and hack >>> around it. >> >> Fair point. Insert "should we get rid of a.out exec, too?" here :-) > > No... > > -- > David A. Holland > dholl...@netbsd.org

Re: svr4, again

> On Dec 19, 2018, at 5:06 PM, matthew green wrote: > > i would argue that until we're willing to drop a.out exec > entirely we should keep the above. let's not chip and hack > around it. Fair point. Insert "should we get rid of a.out exec, too?" here :-) -- thorpej

Re: svr4, again

> On Dec 19, 2018, at 3:38 PM, Jason Thorpe wrote: > > Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less > vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUNOS, is a > pretty thin layer, but also of questionable utility these days

Re: svr4, again

> On Dec 19, 2018, at 1:48 PM, Johnny Billquist wrote: > > Unless I remember wrong, it's needed for Ultrix compatibility on VAX (and > maybe MIPS?). Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUN

Re: svr4, again

> On Dec 18, 2018, at 12:39 AM, Maxime Villard wrote: > > I've made one: > > http://wiki.netbsd.org/attic_museum/ > > I took the entries from src/doc/CHANGES. This is great, thanks. -- thorpej

Re: svr4, again

> On Dec 18, 2018, at 4:16 AM, Maxime Villard wrote: > > Judging by the configuration files: > > * COMPAT_SVR4 is available on sparc, sparc64, *68k, sun2, sun3, atari, > hp300, amiga. This is in terms of files.svr4 inclusions. I suspect that > a part of these inclusions were added automat

Re: svr4, again

> On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: > > Now I'm re-putting the subject on the table, because, as if it wasn't > already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep > unintentionally finding bugs in it, and it just doesn't make any sense > to keep it to me.

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 16, 2018, at 4:03 PM, matthew green wrote: > > unfortunately, UVM has no good mechanism for dealing with > large page sizes and AFAICT, netbsd only uses them for > unmanaged mappings for kernels (and thus, is entirely MD > in implementation and use), and we don't try to keep > large-p

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 15, 2018, at 1:53 PM, Jaromír Doleček > wrote: > > Bigger physical pages also reduce size of page tables (big deal if it > e.g. allows to reduce e.g. 4-level to 3-level mapping, but even "just" > factor or two or four is very good) and hence speed up page faults, > and improve TLB ut

Re: [uvm_hotplug] Fixing the build of tests

> On Dec 15, 2018, at 12:51 AM, matthew green wrote: > > we have a general problem in UVM we need to confront some time > fairly soon. it won't be easy to find all the places, and it > won't be easy to test we have found them. > > almost all the page counts in UVM are "int". that overflows

Re: CVS commit: src/sys/dev/i2c

> On Dec 14, 2018, at 2:05 PM, Michael Lorenz wrote: > > Module Name: src > Committed By: macallan > Date: Fri Dec 14 22:05:36 UTC 2018 > > Modified Files: > src/sys/dev/i2c: ds1307.c files.i2c > > Log Message: > add options DSRTC_YEAR_START_2K for machines which use 2000 and

Re: Importing libraries for the kernel

> On Dec 14, 2018, at 6:19 AM, Joerg Sonnenberger wrote: > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC > still easily requires 10k cycles per operation. The implementation is > non-trivial in t

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 12, 2018, at 11:46 AM, Michał Górny wrote: > > c. Add an extra flag to va_vaflags that explicitly indicates timestamps > are supposed to be changed; always ignore tv_sec when it's unset, > otherwise respect tv_sec independently of value. This is part of a bigger problem with how the V

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:54 AM, Christos Zoulas wrote: > > 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 > | &quo

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:38 AM, Jason Thorpe wrote: > > > >> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: >> >> >> This patch: >> >> https://www.netbsd.org/~christos/kmem_expose_address.diff > > PK_KMEM should only be set if

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:38 AM, Jason Thorpe wrote: > > > >> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: >> >> >> This patch: >> >> https://www.netbsd.org/~christos/kmem_expose_address.diff > > PK_KMEM should only be set if

Re: enhance sysctl kern.expose_address

> On Dec 5, 2018, at 8:27 AM, Christos Zoulas wrote: > > > This patch: > > https://www.netbsd.org/~christos/kmem_expose_address.diff 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. -- thorpej

Re: Tidy up / simplify "com" register initialization

> On Dec 5, 2018, at 12:00 AM, Masanobu SAITOH wrote: > > On 2018/12/04 13:53, Jason Thorpe wrote: >> I'm working on an application where I need some additional run-time >> flexibility > > PLEASE! > sys/dev/ic/com.c has some compile time #ifdef 's and

Re: noatime mounts inhibiting atime updates via utime()

> On Dec 4, 2018, at 8:12 PM, Robert Elz wrote: > > I'd probably change it more to be "do it when explicitly asked to, > or whenever the inode is being updated for other reasons and an > atime update could be made" - that is "unless instructed, don't do > inode updates that update nothing but

Tidy up / simplify "com" register initialization

I'm working on an application where I need some additional run-time flexibility in how the "com" driver register map is setup. COM_REGMAP cam do the job, but there is some untidiness around how com_regs is initialized. This patch is a small step in cleaning that up, with some other minor chang

Re: New i2clcd PCF8754 i2c lcd interface module driver

> On Nov 21, 2018, at 10:07 AM, Jason Thorpe wrote: > > Cool. I think i2clcd is too generic of a name, though, in the event there > are other i2c-connected displays that aren't software-compatible with this > one. > > (I have a couple that I'm going to get

Re: New i2clcd PCF8754 i2c lcd interface module driver

Cool. I think i2clcd is too generic of a name, though, in the event there are other i2c-connected displays that aren't software-compatible with this one. (I have a couple that I'm going to get around to playing with, and not 100% certain they're compatible with this one.) > On Nov 21, 2018, at

Re: fixing coda in -current

> On Nov 20, 2018, at 9:55 AM, Brett Lymn wrote: > > Comments? Anyone really care? Honestly, I think we should probably remove it. -- thorpej

Re: API change request. Was => Re: Time accounting on statclock()

> On Nov 18, 2018, at 11:00 AM, Martin Husemann wrote: > > On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote: >> Typo: >> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html > > Ugh - can't you just modify > > CLKF_USERMODE(frame) > CLKF_PC(frame) > CLKF_INTR

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

> On Nov 13, 2018, at 7:15 AM, John Nemeth wrote: > > That's a different kind of unusable. :-) That puts it in > the same camp as strip, where there may be functioning hardware, > but you can't do anything with the hardware. ...and when you can't do anything with the hardware, people do

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

> On Nov 12, 2018, at 1:59 PM, John Nemeth wrote: > > On Nov 12, 1:16pm, Jason Thorpe wrote: > } Subject: Re: Things not referenced in kernel configs, but mentioned in fil > } > On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > } > > } > wbsio and wt also

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

FWIW, it's not a great idea to throw all of the i2c drivers into a kernel what will ever be booted, because of the i2c address assignment situation. > On Nov 12, 2018, at 2:15 PM, Brad Spencer wrote: > > > co...@sdf.org writes: > >> This is an automatically generated list with some hand touch

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

> On Nov 12, 2018, at 11:12 AM, John Nemeth wrote: > > wbsio and wt also seems to fit in that category. Isn't "wt" an ancient PC tape drive? We should make an effort to prune more deadwood drivers. -- thorpej

Re: Concurrent trie-hash map

> On Oct 16, 2018, at 1:00 PM, Mindaugas Rasiukevicius wrote: > > Hi, > > I recently implemented thmap [1] -- a concurrent trie-hash map, combining > the elements of hashing and radix trie. It is supports lock-free lookups > and concurrent inserts/deletes. It is designed to be optimal as a

Re: libnv

> On Aug 27, 2018, at 2:25 PM, David Holland wrote: > > On Mon, Aug 27, 2018 at 08:41:43AM -0700, Jason Thorpe wrote: >>> [proplib] >> >> Let me try to address these points one by one: > > Now that you're back, can you explain a few more basic po

Re: libnv

> On Aug 27, 2018, at 7:49 AM, Mindaugas Rasiukevicius wrote: > I do not think there was any conclusion either, or a conclusion that > we always want to have static serialisation with a schema (IMO, there > are pros and cons in both cases). Worth noting that there are multiple > libraries alr

Re: Too many PMC implementations

> On Aug 23, 2018, at 8:47 AM, Anders Magnusson wrote: > I have used it not long ago for vax. Maybe I did have to do some tweaks, do > not remember, > but I really want to be able to use kernel profiling on vax. > > So, I really oppose removing it and leaving vax without any kernel profiling

Re: Too many PMC implementations

> On Aug 17, 2018, at 8:42 AM, Kamil Rytarowski wrote: > > Speaking realistically, probably all the recent software-based kernel > profiling was done with DTrace. Yah, I suppose I'm okay will killing off kernel GPROF support ... you can essentially do the same-thing-but-better with an on-cpu

Re: 8.0 performance issue when running build.sh?

> On Aug 9, 2018, at 10:40 AM, Thor Lancelot Simon wrote: > > Actually, I wonder if we could kill off the time spent by fileassoc. Is > it still used only by veriexec? We can easily option that out of the build > box kernels. Indeed. And there are better ways to do what veriexec does, in an

Re: mutex_oncpu() called on destroyed mutex? (was: repeated panics in mutex_vector_enter (from unp_thread))

> On Aug 7, 2018, at 9:44 AM, Edgar Fuß wrote: > > I observe this on 6.1, but I can't see the relevant code changed in current. > > mutex_vector_enter() does (-current uses KPREMPT_* macros) > > do { > kpreempt_enable(); > SPINLOCK_BACKOFF(count); >

Re: 8.0 performance issue when running build.sh?

> On Aug 6, 2018, at 12:17 PM, Rhialto wrote: > > 21.96 24626 82447.93 kernel_lockip_slowtimo+1a The work that's happening here looks like a scalability nightmare., regardless of holding the kernel lock or not. A couple of things: 1- It should do a better job of determining

Re: Proposal: rename min/max -> umin/umax

> On Aug 5, 2018, at 9:32 AM, Taylor R Campbell > wrote: > > I propose we rename libkern's min/max to umin/umax. The names min and > max invite general use like MIN and MAX, but these functions truncate > their arguments to unsigned first. We also have imin/imax, lmin/lmax, > and ulmin/ulma

Re: NetBSD/usermode link issues

> On Aug 4, 2018, at 7:45 AM, Reinoud Zandijk wrote: > > Hi folks, > > as you might know, i'm currently working on NetBSD/usermode.amd64 but I can > use some help with the following linking issue: NetBSD/usermode seems a little wacky in that it's intended to run on some host system, right?

Re: ioctl(2) numbers

> On Aug 1, 2018, at 2:56 AM, Robert Swindells wrote: > > > Does it matter if ioctl(2) numbers overlap so long as they are in > different groups ? It's perfectly fine. They simply need to be unique within the group. -- thorpej

Re: Removing dbregs

> On Jul 13, 2018, at 2:22 PM, Kamil Rytarowski wrote: > > On 13.07.2018 23:10, Jaromír Doleček wrote: >> 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >>> I disagree with disabling it. The code is not broken, it's covered by >>> tests, it's in use. >> >> This looks like perfect candidate for

Re: Removing dbregs

> On Jul 13, 2018, at 12:31 PM, Maxime Villard wrote: > > So why not remove the code? No objection from me. -- thorpej

Re: Too many PMC implementations

Speaking as someone who was peripherally involved in the PMC flavor below, I have no objections to this. > On Jul 11, 2018, at 9:22 AM, Maxime Villard wrote: > > Right now we have three (or more?) different implementations for Performance > Monitoring Counters: > > * PMC: this one is MI. It is

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

> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: > > In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least > for the use of acpica (which still contains a fallback for Itanium > without misaligned access, but not actively maintained). > > Linux uses a different approach

Re: new errno ?

> On Jul 6, 2018, at 2:49 PM, Eitan Adler wrote: > > For those interested in some of the history: > https://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000791.html > ...and the subsequent thread went just as I

Re: mutex question

> On Jul 6, 2018, at 4:48 PM, Phil Nelson wrote: > > Hello, > >The FreeBSD 802.11 code is using a call to mtx_sleep(). The define is: > > #define mtx_sleep(chan, mtx, pri, wmesg, timo) \ >_sleep((chan), &(mtx)->lock_object, (pri), (wmesg), \

Re: usb_rem_task_wait

> On Jul 1, 2018, at 8:18 AM, Taylor R Campbell > wrote: > >> Date: Sun, 01 Jul 2018 08:02:11 -0700 >> From: Jason Thorpe >> >> I've been thinking about this interface a bit... it would be handy >> to have a version of it for some non-usb

Re: usb_rem_task_wait

If you have a newer draft handy, would definitely be interested in looking at it. -- thorpej Sent from my iPhone. On Jul 1, 2018, at 8:18 AM, Taylor R Campbell wrote: >> Date: Sun, 01 Jul 2018 08:02:11 -0700 >> From: Jason Thorpe >> >> I've been thinking abo

Re: usb_rem_task_wait

> On Jun 30, 2018, at 11:58 PM, Taylor R Campbell > wrote: > > The attached patch implements usb_rem_task_wait and uses it in various > drivers' detach routines so that they have a chance of guaranteeing > not to leave pending tasks floating around using memory after free. > Also changes vari

Re: CVS commit: src/sys/kern

> 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 console output unreadable. > > They are fine after mountroot, but is there really any use for them before? +1 --

Re: urtwn driver is spammy

I’m currently doing some work on the urtwn driver to address some problems in my local setup - stay tuned. -- thorpej Sent from my iPhone. > On Jun 28, 2018, at 3:49 AM, Benny Siegert wrote: > > On Thu, Jun 28, 2018 at 12:47 PM Radoslaw Kujawa > wrote: >> >> >> >>> On 28 Jun 2018, at 12:35

Re: More i2c auto configuration improvements

> On Jun 14, 2018, at 3:12 PM, Paul Goyette wrote: > > BTW, why do you use > > return (0); > > in some of the drivers, while others use > > return 0; > > ? > > Shouldn't we standardise on one or the other? I think it boils down to which lines I typed myself :-) (I tend to pr

More i2c auto configuration improvements

I’ve gone through all of the i2c drivers I can find in the source tree and audited their auto configuration scheme. Each of the drivers has been updated to return the “match quality” values introduced in the previous set of changes. To review, those “match quality” values are: — Address-only:

Re: i2c and indirect vs. direct config

> On Jun 6, 2018, at 10:21 AM, Jason Thorpe wrote: > > Turns out there are quite a few bugs in the bcm2835 i2c driver as well, that > tripped up my testing, so I’m going to have to spend a few more evenings on > it, sigh. Well, I managed a minimal change to prevent the infi

Re: i2c and indirect vs. direct config

> On Jun 5, 2018, at 9:21 AM, Jason Thorpe wrote: > > > >> On Jun 5, 2018, at 6:05 AM, Jason Thorpe > <mailto:thor...@me.com>> wrote: >> >> Anyway, I haven’t even compiled this patch yet, but at least you’ll get the >> idea… > > >

Re: i2c and indirect vs. direct config

> On Jun 5, 2018, at 6:05 AM, Jason Thorpe wrote: > > Anyway, I haven’t even compiled this patch yet, but at least you’ll get the > idea… Indeed, there was a typo in it, but the rest of it stands :-) -- thorpej

Re: i2c and indirect vs. direct config

On Jun 5, 2018, at 1:19 AM, Paul Goyette wrote:I think I like this approach.But I'm unclear on how/where the i2c-SMBus device's property-list getsset in the first place.For modular drivers loaded from the file-system after the system is upand running, there is a module prop-list

Re: i2c and indirect vs. direct config

> On Jun 3, 2018, at 7:44 AM, Jason Thorpe wrote: > > Actually, I am thinking more of a set of properties that control the behavior > of the generic i2c code: To follow-up, I think I have this sorted out. There were a couple of other issues with how indirect-config was taking

Re: i2c and indirect vs. direct config

> On Jun 4, 2018, at 2:47 PM, Jason Thorpe wrote: > > > >> On Jun 3, 2018, at 7:44 AM, Jason Thorpe wrote: >> >> Actually, I am thinking more of a set of properties that control the >> behavior of the generic i2c code: > > To follow-up, I t

<    1   2   3   4   5   >