Fwd: futex(2) not working in inherited mmap'd anon memory

-- Forwarded message - From: Thomas Munro Date: Tue, Oct 26, 2021 at 5:36 AM Subject: futex(2) not working in inherited mmap'd anon memory To: Hello, When I do mmap(MAP_ANONYMOUS | MAP_SHARED) and then fork(), it seems that futex(2) wakeups are not delivered between child and

Fwd: explicit_bzero vs. alternatives

moving to tech@ -- Forwarded message - From: Philipp Klaus Krause Date: Mon, Aug 10, 2020 at 4:34 AM Subject: explicit_bzero vs. alternatives To: OpenBSD has the explicit_bzero function to reliably (i.e. even if not observable in the C abstract machine) overwrite memory with

Rename ps_flags to ps_pwmflags in /sys

Hi, These files are only hooked up to the build on arm64, and I don't have this arch, so this is not even compile tested by me. Hopefully, did not miss anything in grepping. Can somebody with arm64 please compile and report any issues? Thanks Index: dev/fdt/amlpwm.c

Re: Rename ps_flags -> ps_sigflags in struct sigacts

> > > > I have the same issue with ps_flags vs ps_flags and I think it resulted in > > some major confusion for others as well. See inline. > > I agree this would make grep/looking at code easier :o) > > > > @@ -336,9 +336,9 @@ setsigvec(struct proc *p, int signum, st > > >

Rename ps_flags -> ps_sigflags in struct sigacts

Hi, In grepping for ps_flags in /sys, it is confusing to see that ps_flags is associated with 1) PWM_POLARITY (power regulation?). Proposed to rename to ps_pwmflags? 2) process signals: struct sigacts in /sys/sys/signalvar.h 3) its rightful usage as ps_flags for struct process in

kern_exit.c : 2 tiny buglets + a potential uvm leak

Hi, 1) pr->ps_ru is already NULL, so code can be shrunk. 2) missing timeout_del, we clear the 2 timeouts in struct process, but not from struct proc. 3) ps_mainproc is allocated in thread_new(), passed to process_new(), and then to process_initialize(). ps_mainproc never gets a call to

Re: Debugger, traced processes & exit status

Hi, > @@ -303,6 +312,7 @@ struct process { > #define PS_PLEDGE 0x0010 /* Has called pledge(2) */ > #define PS_WXNEEDED 0x0020 /* Process may violate W^X */ > #define PS_EXECPLEDGE 0x0040 /* Has exec pledges */ > +#define PS_ORPHAN

Part 2: reduce SCHED_LOCKing while a proc is running

Hi, This is part 2 of previous diff sent earlier and includes it also: "sync quantum for a proc with its per-CPU tracking". While a proc is running, try not to disturb its running. Only change proc priority just before adding to runqueue. This reduces SCHED_LOCK occurences in kernel by a tiny

sync quantum for a proc with its per-CPU tracking

Hi, This diff makes sure that a proc and its per-CPU structure which tracks when to schedule another proc in round-robin are in sync. No observable change in time spent compiling the bsd.mp kernel. This diff in addition with another which replaces schedclock() with equivalent code, shaves

Re: sched_steal_proc(): steal from highest loaded CPU

> > 'ci' changes after we proceed to another cpu, and cost will be different > > for each cpu+proc combination. > > Look at at line 516 of kern/kern_sched.c doest the first argument of > sched_proc_to_cpu_cost() change? Aaaargh, you are absolutely right! My fault, I was blinded by looking at

Re: sched_steal_proc(): steal from highest loaded CPU

(cost > bestcost) { > > best = p; > > bestcost = cost; > > } a break statement right here. > > @@ -524,7 +524,6 @@ sched_steal_proc(struct cpu_info *self) > > if (best == NULL) > > return (NULL); > > > > - spc = >p_cpu->ci_schedstate; > > remrunqueue(best); > > best->p_cpu = self; > > > > -- Amit Kulkarni

sched_steal_proc(): steal from highest loaded CPU

Hi, When a cpu is idle, and wants to steal, it should steal from worst loaded cpu, i.e. with the highest cost, not the least cost. Also, remove a dead store while here. Thanks Index: kern/kern_sched.c === RCS file:

SMR question

Hi, Is the purpose of smr_grace_wait() to round robin the curproc through all CPUs, to make sure all CPUs have passed the quiescent state? Is this line of thinking correct or flawed? I was preparing a diff and wanted to know if it is safe to disable the SMR kthread by commenting it out for

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

> root on sd2a (88532b67c09ce3ee.a) swap on sd2b dump on sd2b > TSC skew=-6129185140 drift=170 > TSC skew=-6129184900 drift=-10 > TSC skew=-6129184890 drift=-20 > TSC skew=-6129184910 drift=30 > TSC skew=-6129184910 drift=10 > TSC skew=-6129184900 drift=20 > TSC skew=-6129184910 drift=30 > iwm0:

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

On Fri, 21 Jun 2019 21:54:18 -0700 Mike Larkin wrote: > On Fri, Jun 21, 2019 at 05:11:26PM -0300, Martin Pieuchot wrote: > > On 06/06/19(Thu) 15:16, Martin Pieuchot wrote: > > > On 02/06/19(Sun) 16:41, Martin Pieuchot wrote: > > > > On 01/06/19(Sat) 18:55, Martin Pieuchot wrote: > > > > > Diff

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

On Sun, Jun 9, 2019 at 10:39 PM Theo de Raadt wrote: > > Amit Kulkarni wrote: > > > > Index: sys/sysctl.h > > > === > > > RCS file: /cvs/src/sys/sys/sysctl.h,v > > > retrieving rev

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

> Index: sys/sysctl.h > === > RCS file: /cvs/src/sys/sys/sysctl.h,v > retrieving revision 1.188 > diff -u -p -r1.188 sysctl.h > --- sys/sysctl.h 1 Jun 2019 14:11:18 - 1.188 > +++ sys/sysctl.h 1 Jun 2019 16:36:13

Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

Hi, This is pretty cool diff in splitting the sleep prio and the run prio! In a few places, the documentation comment could be changed from process to proc, tried to find it below and mark. It leaves reader confused for a moment. thanks > > - `spc_curpriority' is now updated at every

Re: scheduler small changes

> > > The only reason I added quantum, was that I stumbled on the round robin > > > interval buglet. Initially added a fixed 100 ms per proc, and then > > > decided how much I could explore this quantum idea while still trying to > > > keep the code understandable. > > > > Which buglet?

Re: scheduler small changes

Hi, Sorry for slacking off earlier, I was trying to recharge myself with some time off without looking at kernel code, and come back with a renewed focus. > > > Regarding the choice of deriving quantum from the priority, are you sure > > > the priorities are correct? Should we keep priorities?

Re: scheduler small changes

On Thu, 16 May 2019 15:15:24 -0300 Martin Pieuchot wrote: > On 16/05/19(Thu) 00:08, Amit Kulkarni wrote: > > [...] > > > Regarding the choice of deriving quantum from the priority, are you sure > > > the priorities are correct? Should we keep priorities? Or if user

Re: scheduler small changes

> Why did you decide to change the data structure of the runqueue? What > problem are you trying to solve? Thanks for your feedback. It forced me to do some introspection. I was trying to explore if we can tweak and make the current code faster, while still tryign to keep it as simple as it is

scheduler small changes

Hi, This effort is heavily based on top of Gregor's and Michal's diffs. Tried to incorporate feedback given by different people to them in 2011/2016. Split the new code in a ifdef, so people can do a straight comparison, tried very hard not to delete existing code, just shifted it around. Main

Re: SCHED_LOCK vs 'struct proc'

On Sat, May 11, 2019 at 6:29 PM Martin Pieuchot wrote: > > Document which fields are protected by the SCHED_LOCK(), ok? > > Index: sys/proc.h > === > RCS file: /cvs/src/sys/sys/proc.h,v > retrieving revision 1.263 > diff -u -p

misleading comment in preempt()

there is no process supplied, comment is misleading... diff --git kern/sched_bsd.c kern/sched_bsd.c index 00a08861b59..0b63276d1ff 100644 --- kern/sched_bsd.c +++ kern/sched_bsd.c @@ -318,9 +318,7 @@ yield(void) /* * General preemption call. Puts the current process back on its run queue -

Re: sched_choosecpu_fork()

> In sched_choosecpu_fork(), we see best_run is INT_MAX, the comparison below > actually reduces to a assignment ==> choice = ci; > - if (choice == NULL || run < best_run || > - (run == best_run & < best_load)) { > - choice = ci; > -

Re: sched_choosecpu_fork()

On Wed, 20 Feb 2019 14:08:45 -0300 Martin Pieuchot wrote: > When choosing the initial CPU for a new thread to run on, the scheduler > do not consider that CPU0 is handling interrupts. > > Threads that are created early, like the network taskq, always end up > scheduled on CPU0. If the machine

Re: sysctl kern.pool.XXX

> > This comment below is misleading. There are no such sysctl's. The defines > > are only used in kern/subr_pool.c > > > > ... to implement the sysctls. What are you talking about? > Ah, I see. These are not present, leading me to wonder, why are they being mentioned here?

sysctl kern.pool.XXX

This comment below is misleading. There are no such sysctl's. The defines are only used in kern/subr_pool.c diff --git sys/pool.h sys/pool.h index d2f05227b7a..e97f774a272 100644 --- sys/pool.h +++ sys/pool.h @@ -34,12 +34,6 @@ #ifndef _SYS_POOL_H_ #define _SYS_POOL_H_ -/* - * sysctls. - *

remove 2 duplicate functions in uvm anon

uao_reference() vs uao_reference_locked() uao_detach() vs uao_detach_locked() When you read the code, you can see that both are calling the same function, so fold them into the one function which is used by external callers, and remove the internal function call, but preserve its comments.

Re: replacing timeout_add() with timeout_add_msec()

> You started to convert the wrong timeout_add() calls. Doing a blind > timeout_add() to timeout_add_msec() conversion especially on calls with 0 > or 1 tick sleep time is the wrong approach. > The right approach is to identify calls that do sleep for a well defined time > (1sec, 50ms or whatever)

Re: replacing timeout_add() with timeout_add_msec()

> > Even on amd64, I won't be able to test, because of missing hardware. > > If you think something is wrong, please will you let me have your > > feedback? > > I'm a bit stunned at the zeal to push untested diffs into the tree > > (you didn't ask anyone to test it for you) I requested for

Re: replacing timeout_add() with timeout_add_msec()

Even on amd64, I won't be able to test, because of missing hardware. If you think something is wrong, please will you let me have your feedback? Thanks On Sun, Jan 6, 2019 at 4:56 PM Theo de Raadt wrote: > > Amit Kulkarni wrote: > > > Hi, > > > > Referring

replacing timeout_add() with timeout_add_msec()

Hi, Referring to the end of mpi's message, and also mlarkin@ later comment https://marc.info/?l=openbsd-tech=154577028830964=2 I am trying to replace some easy timeout_add() calls with timeout_add_msec(). My current understanding with the occurences of timeout_add() in the tree is that: if

Re: More km_alloc(9)

> > Had the diff below in my tree for a very long time. Switch several > > uvm_km_alloc()/uvm_km_valloc() calls over to km_alloc(). > > > > ok? > > > > ok but there is a knf spacing issue (end-pa). other than that nit, ok mlarkin > tested to work fine on amd64. thanks

Re: Remove VFSLCKDEBUG + ASSERT_VP_ISLOCKED (dead code in VFS)

> > After reading VOP_LOOKUP.9 based on recent commit, a try to remove some > > dead code in VFS. > > https://marc.info/?l=openbsd-cvs=153886730207657=2 > > > > VFSLCKDEBUG is not defined anywhere. It is misleading to read in > > sys/kern/vfs_vops.c that ASSERT_VP_ISLOCKED(dvp) is being checked,

Remove VFSLCKDEBUG + ASSERT_VP_ISLOCKED (dead code in VFS)

Hi, After reading VOP_LOOKUP.9 based on recent commit, a try to remove some dead code in VFS. https://marc.info/?l=openbsd-cvs=153886730207657=2 VFSLCKDEBUG is not defined anywhere. It is misleading to read in sys/kern/vfs_vops.c that ASSERT_VP_ISLOCKED(dvp) is being checked, when in fact, it

Remove UVM_PAGE_OWN() and remove define UVM_PAGE_TRKOWN

Hi all, Justification for removing this code: 1) This is currently dead code, UVM_PAGE_TRKOWN is undefined in GENERIC on all arches. If it is dead, while reading it gives incorrect impression that this code is useful. 2) The comment for uvm_page_own() mentions tracking down problems in

Re: witness report

On Sun, 3 Jun 2018 13:09:43 -0700 Philip Guenther wrote: > On Sun, Jun 3, 2018 at 12:51 PM, Amit Kulkarni wrote: > > > On Sun, 3 Jun 2018 10:37:30 -0700 > > Philip Guenther wrote: > > > ... > &

Re: witness report

On Sun, 3 Jun 2018 10:37:30 -0700 Philip Guenther wrote: > On Sun, 3 Jun 2018, Theo de Raadt wrote: > > Philip Guenther wrote: > > > The warning is not that a single filesystem is being locked > > > recursively by a single thread, but just that a single thread is > > > holding locks on

Re: de-hole some structs on amd64

Hi, Is there any feedback on this? Thanks > > > I tested removing some slop (i.e. structure packing/de-holing) on amd64, > > > this went through a full kernel + userland build. > > > > > > > Parts of this are probably okay, but there's some stuff which needs better > > placement vs comments

Re: de-hole some structs on amd64

> > I tested removing some slop (i.e. structure packing/de-holing) on amd64, > > this went through a full kernel + userland build. > > > > Parts of this are probably okay, but there's some stuff which needs better > placement vs comments and at least one move which needs a justification for > it

de-hole some structs on amd64

Hi, I tested removing some slop (i.e. structure packing/de-holing) on amd64, this went through a full kernel + userland build. struct proc 20 bytes (6 places) --> 4 bytes (2 places) struct process 28 bytes (6 places) --> 4 bytes (1 place) struct vm_map 8 bytes (2 places) --> 0 bytes Thanks

Re: elf.h

> So with this base is compilable and runnable on AMD64. W.r.t. ports, yes, > some of those fails. I've not investigated more closely strange failures > which may be a cause of me not cleaning up fs from previous snapshots -- this > machine is basically 2 years old snapshots accumulation

Re: Better handling of short reads

On Wed, Jun 14, 2017 at 4:56 AM, Mike Belopuhov <m...@belopuhov.com> wrote: > On Thu, Jun 08, 2017 at 11:55 +0200, Mike Belopuhov wrote: >> On Wed, Jun 07, 2017 at 23:04 -0500, Amit Kulkarni wrote: >> > On Wed, 7 Jun 2017 21:27:27 -0500 >> > Amit Kul

Re: Better handling of short reads

On Wed, 7 Jun 2017 21:27:27 -0500 Amit Kulkarni <amit.o...@gmail.com> wrote: > On Thu, 8 Jun 2017 01:57:25 +0200 > Mike Belopuhov <m...@belopuhov.com> wrote: > > > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: > > > Wow, please get this in!!

Re: Better handling of short reads

On Thu, 8 Jun 2017 01:57:25 +0200 Mike Belopuhov <m...@belopuhov.com> wrote: > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote: > > Wow, please get this in!!! > > > > This fixes cvs update on hard disks, to go much much faster. When I am > > updating

Re: Better handling of short reads

Wow, please get this in!!! This fixes cvs update on hard disks, to go much much faster. When I am updating the entire set of cvs trees: www, src, xenocara, ports, I can still use firefox and have it perfectly usable. There's a night and day improvement, before and after. Thanks for debugging and

Remove KGDB leftover in i386/amd64 GENERIC

Index: amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.442 diff -u -p -u -p -r1.442 GENERIC --- amd64/conf/GENERIC 12 Mar 2017 21:31:18 - 1.442 +++ amd64/conf/GENERIC 30 Apr

remove cpuset dead code

Unused under /sys, survived a kernel build without problems. Index: kern/kern_sched.c === RCS file: /cvs/src/sys/kern/kern_sched.c,v retrieving revision 1.44 diff -u -p -u -p -r1.44 kern_sched.c --- kern/kern_sched.c 21 Jan 2017

Re: Futexes for OpenBSD

The new files should have the ISC/OpenBSD license inserted at the top. IMHO, the ticket changes are a separate diff and you will be able to commit that part first. Also, replacing struct _spinlock with int is also a separate diff. Those changes don't clash with futexes, so less chance of being

Re: Not enough inodes on /usr for ports/xenocara

On Tue, Jun 14, 2016 at 8:41 AM, Marc Peters wrote: > Hi, > > i just did an installation of a HP DL360 Gen9 to test UEFI installations > with 5.9. I just accepted most of the defaults and did this for the > disklabels, too. I wanted to checkout the sources to do release builds,

Requesting /usr/bin/doas to be moved to /bin

The title says it all. Is there any interest in moving doas so that it can be statically compiled in without depending on libc.so? I am also surprised su and login are in /usr/bin. A few minutes ago, I mistakenly deleted libc.so. I had several shells open but no root shell :(. I recovered

Options DDB/DIAGNOSTIC

Hello, There is a bunch of code which is always on, but ifdef'd DDB/DIAGNOSTIC. Those options have been turned on forever in GENERIC. Any interest in removing code like this? The ifdef/endif DIAGNOSTIC will just be removed by unifdef... If there is any interest, I will go file by file and

Re: Scheduler hack for multi-threaded processes

On Tue, Mar 22, 2016 at 10:00 AM, Douglas Ray <doug...@cpan.org> wrote: > On 21/03/16 11:29 AM, Mark Kettenis wrote: > >> From: Amit Kulkarni <amitk...@gmail.com> >>> Date: Sun, 20 Mar 2016 17:57:49 -0500 >>> >> ... > >> +1. Previou

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 19, 2016 at 4:35 PM, Bob wrote: > > I'm also interested in hearing from more people using multi-threaded >> applications. >> > > I applied the patch to my old core duo p7570 running CURRENT/amd64. > Firefox is more responsive and youtube videos, previously

Re: New scheduler for OpenBSD

On Sat, Mar 12, 2016 at 10:36 AM, Michal Mazurek wrote: > Gregor Best attempted to improve the scheduler in 2011: > http://comments.gmane.org/gmane.os.openbsd.tech/27059 > Here is another attempt, it takes up where the previous one left off. > > This is also mostly based on

mention /etc/doas.conf instead of plain doas.conf

I just switched from sudo to doas and was stumped by this. The doas code expects doas.conf in /etc yet the manpage does not explicitly make that clear. I added a SYNOPSIS like in "man login.conf". Thanks Index: doas.conf.5 === RCS

Re: printf(3) wording

On Tue, Nov 17, 2015 at 11:22 AM, Jason McIntyre wrote: > On Tue, Nov 17, 2015 at 06:14:33PM +0100, Jan Stary wrote: > > On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > > > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > > > I am not a native speaker, but the

Re: sqlite 3.8.11.1

On Wed, Sep 9, 2015 at 11:12 AM, Miod Vallat wrote: > > > When espie@ imported sqlite he wanted to follow upstream so he > imported > > > what was distrubuted with sqlite. Since then we do tagged (based on the > > > sqlite version) imports whenever we do an update. So when a diff

Re: apmd hangs

On Tue, Sep 9, 2014 at 2:13 PM, David Coppa dco...@gmail.com wrote: On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze schwa...@usta.de wrote: Hi David, David Coppa wrote on Tue, Sep 09, 2014 at 07:44:47PM +0200: On Tue, Sep 9, 2014 at 7:27 PM, Ingo Schwarze schwa...@usta.de wrote: i'm

Re: lynx: disable old protocols

On Wed, Jul 16, 2014 at 4:00 PM, Shawn K. Quinn skqu...@rushpost.com wrote: On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this

remove obsolete variables NKMEMPAGES_MIN/ NKMEMPAGES_MAX

Index: regress/usr.bin/diff/t8.2 === RCS file: /cvs/src/regress/usr.bin/diff/t8.2,v retrieving revision 1.1 diff -u -p -r1.1 t8.2 --- regress/usr.bin/diff/t8.2 17 Jul 2003 21:04:04 - 1.1 +++ regress/usr.bin/diff/t8.2 7

Re: man pages: wireless frequency nit 2GHz vs 2.4GHz

On Thu, Feb 14, 2013 at 6:33 AM, Stuart Henderson s...@spacehopper.orgwrote: Amit Kulkarni amitkulz at gmail.com writes: I was reading the manpages of athn/iwn for purchasing a suitable wireless card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz

Re: man pages: wireless frequency nit 2GHz vs 2.4GHz

a section of athn.4 manpage is fluff, information is repeated twice. once in words, other times in a table summarizing the list of working/supported chips. the same manpage was copied over for iwn, a table of supported chips would be nice in there too. if there's any interest i will sit

man pages: wireless frequency nit 2GHz vs 2.4GHz

I was reading the manpages of athn/iwn for purchasing a suitable wireless card and found repeated occurences of 2GHz, when in fact it should be 2.4GHz. That is the standard frequency when purchasing a wireless a/b/g/n card. The code is filled with 2GHz references but just changed to man pages

missing include in sys/proc.h?

While porting boost-1.52.0 (latest boost) and checking affected ports, I came across this. c++ -o src/mapped_memory_cache.os -c -DHAVE_JPEG -pthread -ansi -Wall -pthread -ftemplate-depth-300 -DOPENBSD -DBOOST_SPIRIT_THREADSAFE -DMAPNIK_THREADSAFE -O3 -finline-functions -Wno-inline -DNDEBUG

Re: upstream vendors and why they can be really harmful

Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. They occupy a few people in our team FULLTIME with respect to gnome, they're the reason we still DON'T have a full kde4 in our tree (hopefully to be addressed shortly), and they're

Re: ln -s example

shouldn't this order be flipped? the example does what its description says. why do you think it should be reversed? because people are often confused by symlinks? I always tell the confused: the order is the same as cp(1): the first argument needs to exits, the second one is created.

ln -s example

shouldn't this order be flipped? Index: ln.1 === RCS file: /cvs/src/bin/ln/ln.1,v retrieving revision 1.29 diff -u -p -r1.29 ln.1 --- ln.12 Mar 2011 07:47:21 - 1.29 +++ ln.119 Sep 2012 23:27:04 - @@

Re: Hibernate support

2. Hibernate writes to swap (at the end of your swap). If you have too small a swap, it won't work, or if there are swap pages in use at the end of your swap that overlap with what we want. You need at least size of mem + 64MB of swap at the end of swap, free, at the time of hibernate.

Re: C Programming Language - KR books to be given...

On Mon, Jul 2, 2012 at 4:47 AM, Amarendra Godbole amarendra.godb...@gmail.com wrote: Hi misc@, tech@, If it is difficult to grab hold of a copy of KR 2nd ed., please drop me a private note -- I have a bunch of copies (5) which I can send across your way as a gift. I'll probably ask you to

Re: Remove timezone support from the kernel

On Tue, Apr 24, 2012 at 7:35 AM, Stuart Henderson s...@spacehopper.org wrote: On 2012/04/24 16:27, Vadim Zhukov wrote: 23 P0P?QP5P;Q 2012B P3. 21:37 P?PP;Q P7PP2P0Q P5P;Q Matthew Dempsky matt...@dempsky.org P=P0P?P8Q P0P;: There's no reason for the kernel to track the system's timezone

Re: Remove timezone support from the kernel

(tv, atv, sizeof(atv))) != 0) + return (error); + TIMEVAL_TO_TIMESPEC(atv, ts); if ((error = settime(ts)) != 0) return (error); } - if (tzp) - tz = atz; return (0); } -- Amit Kulkarni

Re: Making time_t deal with the coming epoch

err. this is a april fool right, guys? :-) On Sun, Apr 1, 2012 at 1:13 PM, Nicholas Marriott nicholas.marri...@gmail.com wrote: Can I make it wake up again automatically three days later? On Sun, Apr 01, 2012 at 06:35:08PM +0200, Benny Lofgren wrote: On 2012-04-01 09.05, Theo de Raadt

Re: Allow clang++ to work on OpenBSD

On Mon, Dec 12, 2011 at 10:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon,

Re: tar -J for xz

this diff adds a -J flag to tar that calls xz for compress/decompress. Requires you to install the xz package on your system. No way. Base never depends on external things. http://git.tukaani.org/?p=xz.git;a=tree Probably can't import xz into base as parts of xz are GPL v3.

Re: wscanf

wscanf based on our scanf implementation. The delta from narrow to wide character support was obtained from FreeBSD and modified to fit our code. Does not include a libc bump yet! Here are corresponding libstdc++ changes, also without bumps. The gcc3 version will have to be revisited

Re: ksh history corruption

FWIW, I like this... makes it better for me to atleast grab some stuff and copy over ***if*** it corrupts again. thanks On Thu, Sep 1, 2011 at 3:22 PM, Marco Peereboom sl...@peereboom.us wrote: Alright this diff keeps the file open and appends lines to HISTFILE. It only rewrites HISTFILE at

Re: custom udp/tcp ports for mountd, rpc.statd, rpc.lockd

Do you have a particular usage that needs this? No, I just run a local nfs server; at the moment only serving one single, trusted client. So I'm not in desperate need for fixed ports, but I think fixed ports are a lot cleaner and over all easier to maintain. RPC does not work that way.

Re: setrlimit code

remove that rlimit code, rc.d and login classes do it much betterer these days. screaming bob ok claudio Similar code is in a few other places, if it's going from bgpd it should be zapped there too. Should we add login.conf sections for bgpd, ftp-proxy, inetd, relayd, smtpd and

Re: Fix running ldd against multiple shared objects

On Fri, Apr 8, 2011 at 6:17 PM, Matthew Dempsky matt...@dempsky.org wrote: Diff below fixes ldd /usr/lib/*.so.* so that it outputs more than just the first shared object's dependencies, like the behavior from ldd /usr/bin/*. The issue is that dlopen(f, RTLD_TRACE) calls exit() after it's

Re: vmmap replacement, please test

there is a newer diff; I won't post the whole thing but in uvm_map.c around line 5954, replace this: KASSERT(start = srcmap-min_offset end = srcmap-max_offset); with this: if ((start PAGE_MASK) != 0 || (end PAGE_MASK) != 0 || end start) return EINVAL;

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

system32 - 64 bit dll + apps sysWOW - 32 bit dll + apps How's that for backwards compatibility. That's utterly ridiculous. The guy responsible for such things should be fired :)

Re: malloc: speedup chunk housekeeping

The random number is derived from a global, which is incremented by a few bits every time a chunk is needed (with a small optimization if only one free slot is left). I have no feedback on this diff but a question on random placing in another two functions. In static void unmap()

Re: malloc: speedup chunk housekeeping

malloc_cache is a power of the, so a bitwise and with malloc_cache - 1 is equivalent to modulo malloc_cache. of two, that is. Room is reserved for MALLOC_MAXCACHE pointers, but only malloc_cache are ever used. So doing a modulo malloc_cache is ok. Ahh, sorry for that. I was thrown by that

Re: Fix running ldd against multiple shared objects

hi. i have commented out the -x stuff for now, and removed it from usage(). the rest of your diff is for other people though, so i'll leave it there. jmc It isn't my diff, its from matthew@. I just diffed on top of it. thanks

Re: Fix running ldd against multiple shared objects

Diff below fixes ldd /usr/lib/*.so.* so that it outputs more than just the first shared object's dependencies, like the behavior from ldd /usr/bin/*. The issue is that dlopen(f, RTLD_TRACE) calls exit() after it's done. I looked into changing this to properly cleanup and return, but

Re: malloc: speed vs randomization

This diff implements a tradeoff to gain speed at the cost of reducing the randomness of chunk allocation in malloc slightly. The idea is only to randomize the first half of chunks in a page. The second half of chunks will fill in the gaps in-order. The effectiveness of the

Re: Compiling the kernel with pcc

Hi, clang still can't compile the kernel on amd64 and presumably all other architectures. And I had sent a email to that effect to clang list. I had a env CC=clang make clean make depend make in my build_kernel.sh file it only works when you have env CC=clang make The recent removal of

spurious sys/types.h include in man pages

Maybe I am missing something but the following manpages don't really need sys/types.h. I compiled some small programs without sys/types.h. thanks, amit Index: mincore.2 === RCS file: /cvs/src/lib/libc/sys/mincore.2,v retrieving

Re: ld.so speedup for large binaries with many shared libraries

from http://www.feyrer.de/NetBSD/bx/blosxom.cgi/index.front?-tags=arm http://mail-index.netbsd.org/tech-userlevel/2010/02/24/msg003325.html it will help Chrome, Firefox, Webkit, GNOME, KDE, LibreOffice, vlc (and similar monsters like those) On Sun, Apr 24, 2011 at 4:53 AM, Antti Harri

Re: namespace.h

Just commented out that shm_open/unlink portion, yes yes I know its bad. But spawn.h + posix_spawn.c is absolutely needed for lldb, and it will need heavy commentary from the header guys just like the recent fenv.h changes. Otherwise, the alternative is ugly and a patch set for lldb which is more

Re: namespace.h

where is a listing of all functions implemented in openbsd's libc? nm /usr/lib/libc.a ? What's the question that you're *really* trying to answer? Just trying to see how far llvm+lldb goes in compilation. Right now its stuck because of missing spawn.h in OpenBSD. And also stuck in shm_open,

namespace.h

hi, where is a listing of all functions implemented in openbsd's libc? Is src/lib/libc/include/namespace.h consist of functions not implemented or its a relic? i was looking for the equivalent of FreeBSD's file of the same name and location but in OpenBSD. thanks, amit

Making clang++ actually work ( WAS Re: Changing llvm/clang++ to use libstdc++ from ports instead of base)

Hi, referring to http://marc.info/?l=openbsd-portsm=129789998809077w=2 I am in the process of updating llvm+clang from 2.8 == 2.9 (maintainer is ports@). Done the update on amd64 (will need some feedback) sending as a separate email. Update can go in or not, but clang++ C++ compiler absolutely

Re: fsck_ffs diff needs testing

Also, depending on the usage patterns, you might have a fs where high numbered inodes are used, while the fs itself is pretty empty. Filling up a fs with lots of files and them removing a lot of them is an example that could lead to such a situation. This diff does not speed things up in such

Re: fsck_ffs diff needs testing

Thanks! I understand. On Thu, Apr 7, 2011 at 11:09 AM, Otto Moerbeek o...@drijf.net wrote: On Thu, Apr 07, 2011 at 11:05:42AM -0500, Amit Kulkarni wrote: Also, depending on the usage patterns, you might have a fs where high numbered inodes are used, while the fs itself is pretty empty

Re: Compiling the kernel with pcc

On Mon, 4 Apr 2011, Alexander Bluhm wrote: On Mon, Apr 04, 2011 at 08:06:57PM +0200, Pascal Stumpf wrote: net/pf.c: pf_addr_compare (was probably ok before r1.729) The current implementation has been discussed. See also: http://www.greenend.org.uk/rjk/2003/03/inline.html The function

Re: horribly slow fsck_ffs pass1 performance

-01 19.03, Amit Kulkarni wrote: Thank you Arthur and the team for a very fast turnaround! Thank you for reducing the pain. I will schedule a fsck every month or so, knowing it won't screw up anything and be done really quick. Why schedule fsck runs at all? The file system code is very mature

  1   2   >