-- 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 p
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 ze
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
> >
> > 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
> > > ps->ps_catchmask[si
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 /sys/sy
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 uvm_uarea
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
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
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 appr
> > '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 the
bestcost) {
> > + if (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 = &best->p_cpu->ci_schedstate;
> > remrunqueue(best);
> > best->p_cpu = self;
> >
> >
--
Amit Kulkarni
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: /cvs/src/sys/ker
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 testing
> 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: hw
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 be
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
> 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 -00
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 context-s
> > > 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? Should
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?
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
> 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
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
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 -r1.263
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
- *
> 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 &&load < best_load)) {
> - choice = ci;
> -
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 i
> > 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?
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.
- *
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. Teste
> 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)
> > 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 criti
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
Hi,
Referring to the end of mpi's message, and also mlarkin@ later comment
https://marc.info/?l=openbsd-tech&m=154577028830964&w=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
> > 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
> > After reading VOP_LOOKUP.9 based on recent commit, a try to remove some
> > dead code in VFS.
> > https://marc.info/?l=openbsd-cvs&m=153886730207657&w=2
> >
> > VFSLCKDEBUG is not defined anywhere. It is misleading to read in
> > sys/kern/vfs_vops.c that ASSERT_VP_ISLOCKED(dvp) is being check
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&m=153886730207657&w=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,
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 PG_BUSY
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:
> >
> ...
>
&
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 multipl
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 an
> > 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 b
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
d
> 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 withoug
On Wed, Jun 14, 2017 at 4:56 AM, Mike Belopuhov 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 Kulkarni wrote:
>> >
>
On Wed, 7 Jun 2017 21:27:27 -0500
Amit Kulkarni wrote:
> On Thu, 8 Jun 2017 01:57:25 +0200
> Mike Belopuhov wrote:
>
> > On Wed, Jun 07, 2017 at 18:35 -0500, Amit Kulkarni wrote:
> > > Wow, please get this in!!!
> > >
> > > This fixes cvs update on
On Thu, 8 Jun 2017 01:57:25 +0200
Mike Belopuhov 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 the entire set of cvs trees
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 f
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 20
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 0
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 r
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,
> but the autolayo
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 using
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 send
On Tue, Mar 22, 2016 at 10:00 AM, Douglas Ray wrote:
> On 21/03/16 11:29 AM, Mark Kettenis wrote:
>
>> From: Amit Kulkarni
>>> Date: Sun, 20 Mar 2016 17:57:49 -0500
>>>
>> ...
>
>> +1. Previously, when I did a cvs update with original scheduler cod
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 impossible to
> watch, run s
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 the main idea behind L
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 f
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 conversion specifiers
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 is
> sent
> > >
On Tue, Sep 9, 2014 at 2:13 PM, David Coppa wrote:
> On Tue, Sep 9, 2014 at 7:58 PM, Ingo Schwarze 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 wrote:
> >
> >>> i'm sorry to say it makes no difference
On Wed, Jul 16, 2014 at 4:00 PM, Shawn K. Quinn
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 forum.
>
> Ever
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 J
> > 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
On Thu, Feb 14, 2013 at 6:33 AM, Stuart Henderson wrote:
> Amit Kulkarni 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. T
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 in
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 -DHA
>> 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
>> > 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 on
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 -
@@ -130,
On Wed, Jul 11, 2012 at 5:07 PM, Theo de Raadt wrote:
>> > windows (they do have one of the best hibernate around) creates a
>> > separate pagefile (swap) and a hibernate file. any thoughts of having
>> > a /var/hibernate or something along those lines?
>>
>> hahahhahahhahahahahahh
>
> Indeed.
>
>
> 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.
m
On Mon, Jul 2, 2012 at 4:47 AM, Amarendra Godbole
wrote:
> Hi misc@, tech@,
>
> If it is difficult to grab hold of a copy of K&R 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 cover the shipping
> (~$6
copyin(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
On Tue, Apr 24, 2012 at 7:35 AM, Stuart Henderson
wrote:
> On 2012/04/24 16:27, Vadim Zhukov wrote:
>> 23 P0P?QP5P;Q 2012B P3. 21:37 P?P>P;Q P7P>P2P0Q P5P;Q Matthew Dempsky
>> P=P0P?P8Q P0P;:
>> > There's no reason for the kernel to track the system's timezone
>> > anymore. B This is handled in
err. this is a april fool right, guys?
:-)
On Sun, Apr 1, 2012 at 1:13 PM, Nicholas Marriott
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 wrote:
>> > The epoch isn't
On Mon, Dec 12, 2011 at 10:06 AM, Pascal Stumpf
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
>> >
>> > On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote:
>> > > On Mon, Dec 12, 2011 at 04:00:44PM +0
>> 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.
>> > 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 wil
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 wrote:
> Alright this diff keeps the file open and appends lines to HISTFILE. It
> only rewrites HISTFILE at 125% of HISTSIZE.
>> > 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 wor
>> > > 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, inet
On Fri, Apr 8, 2011 at 6:17 PM, Matthew Dempsky 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 done.
> I looke
> I have used this feature on a regular basis. Very useful when you want
> to politely power off a system, but you don't have/don't want a login.
+1
especially when i am trying off and on to make my xorg.conf work in
dual monitor setup for months, and it hangs. And pressing the power
button for
> 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)
>re
> 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 :)
>> 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
> 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()
> 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
> 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, bu
Ok thanks.
On Wed, Apr 27, 2011 at 12:20 AM, Theo de Raadt wrote:
>> Maybe I am missing something but the following manpages don't really need
>> sys/types.h.
>
> you are wrong.
>
> You are only trying on OpenBSD.
>
> If only everything was OpenBSD.
>
> However, everything is not OpenBSD.
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
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
> > > 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
> > > effectiven
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 wrote:
>
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 o
0 Apr 2011, Joerg Sonnenberger wrote:
> On Tue, Apr 19, 2011 at 11:15:49PM -0500, Amit Kulkarni wrote:
> > 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 reli
>> 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_
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
Hi,
referring to http://marc.info/?l=openbsd-ports&m=129789998809077&w=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
1 - 100 of 123 matches
Mail list logo
