for reference, i use this. faster query interval and when not idle, slam
high immediately.
Index: apmd.c
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.63
diff -u -p -r1.63 apmd.c
--- apmd.c 13 Nov 2013
sprinkle malloc array in the kern directory.
Index: exec_subr.c
===
RCS file: /cvs/src/sys/kern/exec_subr.c,v
retrieving revision 1.36
diff -u -p -r1.36 exec_subr.c
--- exec_subr.c 12 Jul 2014 18:43:32 - 1.36
+++ exec_subr.c
On Sun, Jul 13, 2014 at 11:14, Ted Unangst wrote:
sprinkle malloc array in the kern directory.
And some others from exec that follow a slightly different pattern.
Index: exec_elf.c
===
RCS file: /cvs/src/sys/kern/exec_elf.c,v
On Sun, Jul 13, 2014 at 17:52, Theo de Raadt wrote:
And some others from exec that follow a slightly different pattern.
This is the pattern I have been following as well.
As for the final diff, I've been giving up on the known constant
scenario. It seems expensive.
Meh. :) I think they
On Tue, Jul 15, 2014 at 12:38, Christian Weisgerber wrote:
The reason the Soekris net6501 has hw.ncpufound=1 in bsd.rd is
stupid. The net6501 has MP BIOS, but not ACPI. Only the GENERIC
(thus also GENERIC.MP) and RAMDISK kernels on amd64 and i386 include
mpbios(4), RAMDISK_CD doesn't.
Is
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote:
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this instead:
Hmm I think it's only misleading in the
On Wed, Jul 23, 2014 at 00:02, Mark Kettenis wrote:
Hmm, I believe, quite strongly, that we should always panic when a
arithmetic overflow is detected.
The M_CANFAIL flag is really there to allow for failure in certain
low-memory conditions, not to recover from programming bugs.
The
Was just investigating a little issue with a long running (stuck)
process. I logged in at 9:20PM:
10002 0.0 0.0 3740 2420 ?? S 9:20PM0:00.02 sshd
So you can imagine my surprise to see a cron job running in the future:
24292 0.0 0.0 776 616 ?? Is 9:25PM0:08.51
On Wed, Jul 23, 2014 at 10:20, Hanno Böck wrote:
Hi,
Quick background: Some router firmwares from F5 have a bug that they
fail if the SSL handshake is between 256 and 511 bytes.
Following up that openssl and other major ssl implementations
introduced a TLS padding extension that does
On Wed, Jul 30, 2014 at 23:31, Dmitry Eremin-Solenikov wrote:
Hello,
I have spotted a problem with the patch of crypto/evp/encode.c done by
jsing on May 3.
Sometimes decoding of base64 will fail. For example the attached file
will fail decodiding
(and produce an empty output):
On Thu, Jul 31, 2014 at 18:10, Remco wrote:
Fritjof Bornebusch wrote:
Hi tech,
there is an unnecessary NULL check before calling free.
fritjof
Index: xmalloc.c
===
RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v
retrieving
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/009_dhcp.patch.sig
untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N93/QG6Y9kGPe+DHW4eR6ZbsfLTCXCXAsEwTnx4m/bIm9T9tYjw38rAbRiQWSkDgUvlmxRil/j/ML/4NCynGtfbgU=
OpenBSD 5.5 errata 9, June 30, 2014: Packets with illegal
On Sun, Aug 10, 2014 at 11:38, Nicholas Wilson wrote:
Maybe this is a silly question - but where is the code for the portable
version checked in? I think I understand the development model from working
with OpenSSH dev, but surely the portable compat files must be kept in
version control
Some fixes from OpenSSL 1.0.1i have been backported to 5.5 and 5.4.
See http://www.openbsd.org/errata55.html
untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N930/jzqCCFMfSCKMjKDSYrXSKPhnGlL2r21nCGEPw+wOEDXpQC6Zispe8gewI7duy5T76oRpvWFGyzsYxl6pWfAc=
OpenBSD 5.5 errata 10,
This diff is incomplete, but shows the direction I'm headed.
The current config struct keeps a pointer to various strings (ca file,
etc.). This causes (or will cause) two kinds of trouble.
1. error prone. it's reasonable to create a ca file path by
snprintf into a stack buffer. when that buffer
On Mon, Sep 01, 2014 at 14:03, Jonathan Gray wrote:
This adds support for using the SVR4/glibc word delimeters
in regcomp as an extension to what posix requires.
We already have [[::]] and [[::]] as extensions, apparently
from 'Henry Spencer's Alpha 3.0 regex release' back in 1993.
But
On Fri, Aug 15, 2014 at 13:06, Ted Unangst wrote:
Instead, ressl should copy all parameters as necessary and
free them. This does introduce an error case into formerly void
functions, but I think that's ok. The alternative would be to use
fixed arrays inside ressl_config, but that seems much
On Wed, Sep 10, 2014 at 16:38, Ted Unangst wrote:
On Fri, Aug 15, 2014 at 13:06, Ted Unangst wrote:
Instead, ressl should copy all parameters as necessary and
free them. This does introduce an error case into formerly void
functions, but I think that's ok. The alternative would be to use
On Fri, Sep 12, 2014 at 09:39, Kent R. Spillner wrote:
On Fri, Sep 12, 2014 at 12:38:07AM -0700, Doug Hogan wrote:
Hmm this doesn't look right to me. ressl_config is not allocated the
same way as the other variables. The other variables such as ssl,
sslhost, etc are local to that function
On Sat, Sep 13, 2014 at 04:13, Joel Sing wrote:
I'm not convinced that we should be doing this with the *_mem() functions,
as
there is a benefit to the client owning this memory. Currently, in httpd the
public/private key is removed as soon as ressl_configure() is called.
Obviously libssl
On Mon, Sep 15, 2014 at 20:17, Max Fillinger wrote:
Not really an important issue, but here's a diff to bring the comments
in rnd.c more up to date. In particular:
- The PRNG uses ChaCha20 instead of RC4
- The first few bytes are not thrown away anymore
- The comments list ways to access
On Tue, Sep 16, 2014 at 21:51, David Gwynne wrote:
if you have more than 8 cpus, combine the cpu lines by default.
ok?
very nice.
On Fri, Sep 12, 2014 at 20:04, Ted Unangst wrote:
The neverending slog towards greatness continues.
Index: ressl.c
===
RCS file: /cvs/src/lib/libressl/ressl.c,v
retrieving revision 1.12
diff -u -p -r1.12 ressl.c
--- ressl.c 15
This doesn't change a whole lot, but I'd like to start using the new
bcrypt api where feasible and move away from the crypt wrappers.
Index: encrypt.c
===
RCS file: /cvs/src/usr.bin/encrypt/encrypt.c,v
retrieving revision 1.32
diff
On Wed, Sep 17, 2014 at 01:12, Matti Karnaattu wrote:
Hi,
I found that OpenBSD setpgrp is not POSIX compliant, so I write test and
make diff to fix issue.
Very nice.
http://pubs.opengroup.org/onlinepubs/009695399/functions/setpgrp.html
This change removes obsolete setpgrp, and
On Thu, Sep 18, 2014 at 13:03, Matti Karnaattu wrote:
No, it just shouldn't be present when a conforming environment is
requested. I've fixed unistd.h. to exclude it when you ask for an
XSI conforming environment by building with _XOPEN_SOURCE defined.
(Not sure what about signal.h you're
On Sun, Sep 21, 2014 at 16:20, Mark Kettenis wrote:
Date: Sat, 20 Sep 2014 12:34:42 -0700
From: Philip Guenther guent...@gmail.com
On Sat, Sep 20, 2014 at 11:28 AM, Mark Kettenis
mark.kette...@xs4all.nl wrote:
Date: Sat, 20 Sep 2014 18:15:31 +
From: Miod Vallat m...@online.fr
On Tue, Sep 30, 2014 at 14:18, Stefan Sperling wrote:
If you are bringing an interface up, you're telling the kernel
that you want link on it. Of course, we could stop connecting
to the strongest open network and always require users to type
an nwid before they get link. But that can be
This issue also affects 5.4, 5.5 and 5.6. Patches available in the
respective directories.
5.5 patch follows.
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/011_nginx.patch.sig
untrusted comment: signature from openbsd 5.5 base secret key
On Fri, Oct 03, 2014 at 20:33, Martin Natano wrote:
fusefs_quotactl() unconditionally returns zero, despite fusefs not
supporting quotas. I think it should return EOPNOTSUPP. At least that
is what cd9660, udf, fuse, msdosfs, tmpfs and nfs do.
cheers,
natano
--- fuse_vfsops.c.orig
On Sun, Oct 05, 2014 at 19:42, Martin Natano wrote:
Let's make tree.h conform to style(9).
Index: tree.h
===
RCS file: /cvs/src/sys/sys/tree.h,v
retrieving revision 1.13
diff -u -r1.13 tree.h
--- tree.h9 Jul 2011 00:19:45
Patches are now available to fix two remotely triggerable memory leaks
in the OpenSSL libssl library. This issue affects 5.4 and 5.5. These
issues were originally fixed in forthcoming 5.6 release (it's not
affected).
The patch for 5.5 follows.
untrusted comment: signature from openbsd 5.5 base
This patch disables the SSLv3 protocol for the forthcoming 5.6 release.
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqhqNRnZqpfGyXZORy+gN++chhlgejO0bmLmp81bJL1+Dhl3iP0bL1NnRopcGECX4QoUbsCCcnMOxkXAYeMYkmMgw=
OpenBSD 5.6 errata 5, Oct 20, 2014
This patch disables the
On Wed, Oct 22, 2014 at 16:07, Michael B. Trausch wrote:
I have done a very ugly port that builds and works in the few
scenarios that I've tested with, but it's not complete as some
features (mostly the ones that allow disabling at compile time) need
more work to finish porting.
I think the
On Thu, Oct 23, 2014 at 15:16, Dimitris Papastamos wrote:
Hi everyone,
This is my attempt to add libc wrappers for mkfifo() and
mkfifoat() using mknodat().
Is there a reason? This would seem to do nothing except complicate the
interpretation of ktrace.
On Tue, Oct 28, 2014 at 04:42, Abel Abraham Camarillo Ojeda wrote:
$ while sleep 1; do date; done
Tue Oct 28 04:34:04 CST 2014
Tue Oct 28 04:34:06 CST 2014
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz, 2133.68 MHz
One normal CPU.
cpu0: apic clock
On Tue, Oct 28, 2014 at 16:49, David Gwynne wrote:
when i shuffled the locking in pools around, page colouring was
left behind.
page colouring is where you offset items within a page if you have
enough slack space. the previous implementation simply incremented
the colour so each new page
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
if you want it to go fast, it would make more sense to set the item
alignment in pool_init to the size of the cacheline. colouring would then
become irrelevant from a speed perspective.
There's some sense to this. Like round everything to
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
i dunno. im fine with either removing colouring altogether or setting it
from something else completely. i just want a decision to be made cos
right now ph_color isnt set, which is a bug.
there. i fixed it.
Index: kern/subr_pool.c
On Mon, Oct 13, 2014 at 15:02, Arne Becker wrote:
OK, no more fiddling with O_NONBLOCK.
New diff below, tested with tcpbench and file transfers.
I think this is good. Thanks, committed. We'll let it sit for a while
and then see what if any changes need to take place on the buffer
side. Maybe
kern files, easy fixes.
Index: kern_sensors.c
===
RCS file: /cvs/src/sys/kern/kern_sensors.c,v
retrieving revision 1.29
diff -u -p -r1.29 kern_sensors.c
--- kern_sensors.c 14 Sep 2014 14:17:25 - 1.29
+++ kern_sensors.c
On Thu, Oct 30, 2014 at 22:10, Alexander Bluhm wrote:
+
+ /* Avoid user land starvation. */
+ yield();
I think this is the responsibility of the taskq thread, not the
individual task.
Regarding the second pool diff, that looks very reasonable. Quite a
savings for a feature many
Remove a few bits of junk, mostly support for dso loading of zlib
which i suspect is fully dead.
Index: c_rle.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/comp/c_rle.c,v
retrieving revision 1.7
diff -u -p -r1.7 c_rle.c
--- c_rle.c
Don't need BUF_ and its NULL arg handling here.
Index: x509/x509_trs.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/x509/x509_trs.c,v
retrieving revision 1.16
diff -u -p -r1.16 x509_trs.c
--- x509/x509_trs.c 28 Sep 2014 10:52:59
On Sat, Nov 01, 2014 at 00:26, Joel Sing wrote:
On Fri, 31 Oct 2014, Ted Unangst wrote:
Don't need BUF_ and its NULL arg handling here.
Looks like you need to cvs up... beck@ nuked these and put BUF_strdup()
under
LIBRESSL_INTERNAL about two weeks ago. He missed the comment (second chunk
On Fri, Oct 31, 2014 at 10:24, Matt Markfort wrote:
I have made these recent changes to my personal code base of the
OpenBSD_5_4-release kernel, and it may be useful to commit to -current.
I found the information here for the ATHEROS UB94 USB 802.11a/b/g/n
adapter, and I have tested it with
5.6 is out, rejoice! This means we're going to start emailing patches
for 5.6 instead of 5.5, though of course 5.5 patches will be available
via the website. It also means 5.4 has officially been retired and
won't be receiving any more patches.
When upgrading, take a moment to review the 5.6
several kernel files have a dependency on unistd.h but fail to include
it. (indirect include through file.h, which i'd like to eliminate.)
if you need the file, include it.
and udf_subr.c at least is one file that doesn't need unistd.h
for reference, here's the sys/file.h diff, then the big .c
On Sat, Nov 01, 2014 at 22:45, Ted Unangst wrote:
Pull out a few common subexpressions. I think this makes the code
easier to read. Some byte swaps are left, when they are only used once.
Then use mallocarray for bounds checking.
Also observe the following:
+ if (ghsize
Use knuth shuffle instead of silly shuffle.
Index: canfield.c
===
RCS file: /cvs/src/games/canfield/canfield/canfield.c,v
retrieving revision 1.13
diff -u -p -r1.13 canfield.c
--- canfield.c 29 Aug 2013 20:22:11 - 1.13
+++
First, don't truncate long lines (at least when read from stdin).
Continue printing more cards as necessary.
Second, this fixes a crash on invalid input. Now you can generate a
series of random cards by running cat /dev/random | bcd
Index: bcd.c
On Wed, Nov 05, 2014 at 09:38, David Gwynne wrote:
On 30 Oct 2014, at 07:52, Ted Unangst t...@tedunangst.com wrote:
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
i dunno. im fine with either removing colouring altogether or setting it
from something else completely. i just want
On Tue, Oct 28, 2014 at 16:49, David Gwynne wrote:
when i shuffled the locking in pools around, page colouring was
left behind.
page colouring is where you offset items within a page if you have
enough slack space. the previous implementation simply incremented
the colour so each new page
On Sun, Nov 09, 2014 at 23:44, Nick Holland wrote:
own. You will have a lot of testing to do. You will note that while
deleting rwhod was undoubtedly exciting for developers, actually putting
it on current.html -- so I could put it on upgrade56.html -- was not
nearly as much fun and never
On Mon, Nov 10, 2014 at 13:51, Anthony J. Bentley wrote:
Martin Natano writes:
Index: common/recover.c
===
RCS file: /cvs/src/usr.bin/vi/common/recover.c,v
retrieving revision 1.15
diff -u -r1.15 recover.c
--- common/recover.c
don't back down quite so quick. let the system be idle for 5 ticks
before clocking down.
Index: sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.38
diff -u -p -r1.38 sched_bsd.c
--- sched_bsd.c 3 Nov
the output is easier to interpret and check if it's sorted.
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.287
diff -u -p -r1.287 ifconfig.c
--- ifconfig.c 12 Jul 2014 19:58:17 -
On Wed, Jun 19, 2013 at 14:19, Marc Espie wrote:
On Wed, Jun 19, 2013 at 01:40:19PM +0200, Martin Pelikan wrote:
If you're right that atomic_{clear,set}bits_int is correct and
sufficient and actually faster, then all dynamic executables would
benefit from this speedup (sigprocmask is used
change the junking to be word size. maybe later we can also change the
values to be random or something.
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.149
diff -u -p -r1.149 malloc.c
On Wed, Jul 03, 2013 at 17:21, Theo de Raadt wrote:
+ int pval = 0xd0d0caca;
Can you explain the choice of this?
I thought it sounded clever.
There are arguments to make this MI; other arguments to make it MD;
and other arguments to introduce a bit of randomness.
I'd like to know
On Thu, Jul 11, 2013 at 21:46, Tony Sidaway wrote:
So hi, and if there's anybody else looking at this code, please get in
touch. I hope I'll be able to fix the problems of the device sleeping
in mutexed code. If there is a high likelihood that this code will
soon be removed from the tree,
One machine I use has terminals that happen to be very nicely sized at
75 columns wide. Day to day, this is almost perfect, except when trying
to view a man page, because just a little too much text goes on each
line.
I think mandoc should adjust its default output width based on the
terminal
As per http://research.swtch.com/macpprof
We deliver all prof signals to the main thread, which is unlikely to
result in accurate profiling info. I think the diff below fixes things.
Index: kern/kern_clock.c
===
RCS file:
On Wed, Aug 14, 2013 at 16:51, Ingo Schwarze wrote:
I think mandoc should adjust its default output width based on the
terminal size. At least in the case where the terminal is narrow. This
diff doesn't change anything if you have wider than 80 column terminals.
I agree with your idea for
On Fri, Aug 16, 2013 at 12:33, Mike Belopuhov wrote:
On 16 August 2013 09:23, Ted Unangst t...@tedunangst.com wrote:
Actually, here's my concern. There's only one timeout for the process.
What happens when two threads are running on two CPUs? Is there a
guarantee that cpu0 will both set
On Fri, Aug 16, 2013 at 02:12, Ted Unangst wrote:
As per http://research.swtch.com/macpprof
We deliver all prof signals to the main thread, which is unlikely to
result in accurate profiling info. I think the diff below fixes things.
floating this again. note that it's not the clock being
On Wed, Sep 04, 2013 at 14:28, Reyk Floeter wrote:
Bah. I tend to turn ntpd off and rely on the internal clock
synchronization of the hypervisor. But fixing ntpd inside VMs would
probably be a big win.
Can you explain what you do? I have a vmt timedelta sensor that shows
host time, but how
I think you're in trouble. Some of the software on the openbsd CDs was written
by me,
and I never made any promises it's safe to use on an important
server. Not that you should trust me even if I did make such a promise.
It's software you're getting from the Internet. Made by people from the
On Tue, Sep 17, 2013 at 13:54, Kyle R W Milz wrote:
tech@,
I was porting over some freebsd kernel code and came across a struct
rman and some rman_* utility functions, defined in fbsd's sys/rman.h .
Does obsd have an equivalent interface?
Maybe something like bus_space. Find a FreeBSD
We haven't done a lot of work to optimize performance except in
response to specific issues. Sounds like you found one. Would you
mind providing a test case? I just want to make sure we fix the
right thing.
On Wed, Sep 25, 2013 at 13:12, John Carr wrote:
Problem in a nutshell:
On Thu, Oct 03, 2013 at 18:12, Philip Guenther wrote:
How about we take an idea from FreeBSD and have hardclock() just set a
flag on the thread and then have the thread send SIGPROF (and SIGVTALRM)
to itself from userret(). The signal gets sent by the thread itself right
before it checks for
On Sun, Oct 20, 2013 at 18:00, Maxime Villard wrote:
It should check with VEXEC instead of VREAD. Interpreters get executed,
so they have to be executable; a read-only interpreter shouldn't be
loaded by the kernel.
I am not sure I agree on this.
Why?
How is loading the interpreter
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is did I kill the
On Tue, Oct 22, 2013 at 02:34, Alexander Hall wrote:
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode
On Tue, Oct 22, 2013 at 18:31, William Orr wrote:
You'll notice that there's no significant difference between the output
of the two rngs. However, with octrng the dd completed in under a minute
(more entropy in pool). Without, it took several minutes. If you want
time output, I can add that
On Tue, Oct 22, 2013 at 22:05, William Orr wrote:
I guess I misunderstood, as I thought that /dev/random dumped the entropy
pool, and that /dev/arandom put the random data through a stream cipher so
that grabbing random data would never block.
That was true some time ago, but since at least
@@
/* $OpenBSD: rthread_sem.c,v 1.9 2013/06/01 23:06:26 tedu Exp $ */
/*
- * Copyright (c) 2004,2005 Ted Unangst t...@openbsd.org
+ * Copyright (c) 2004,2005,2013 Ted Unangst t...@openbsd.org
* All Rights Reserved.
*
* Permission to use, copy, modify, and distribute this software for any
On Sat, Oct 26, 2013 at 00:54, Vadim Zhukov wrote:
+/* SHA256_DIGEST_STRING_LENGTH includes nul */
+/* /tmp/ + sha256 + .sem */
Shouldn't this respect the TMPDIR envvar?
No, it's an internal artifact of the implementation.
On Mon, Sep 30, 2013 at 10:38, John Carr wrote:
Here is a diff relative of OpenBSD 5.3 to avoid taking a lock in
pthread_getspecific in the common case where storage for the key is
already allocated.
I have only tested this patch for my use case where a single key is
created once and used
This may be a bad idea. I can't really think of any pros or cons,
other than a general principle of when feasible, prefer random over
deterministic.
Index: softraid_raid1.c
===
RCS file: /cvs/src/sys/dev/softraid_raid1.c,v
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
btw, no library version change because the function stubs already
existed.
Hmm, since this is actually offering new functionality (by sem_open()
and friends no longer always failing), I think it a minor bump would
be appropriate.
We want to be sure the shared semaphore file is sized just right.
If it's not perfect, we'd better be creating it, and if we are
creating it, it'd better be empty.
Index: rthread_sem.c
===
RCS file:
On 2013/11/20 07:40, Shawn K. Quinn wrote:
FreeBSD and Dragonfly BSD have this option in tr. So, this actually
improves portability.
It's just spreading the disease. portable means it works everywhere.
Increasing the number of people who can write nonportable code is not
the same as
Fix a few things. I think I started down the sem inside a sem road
because I misunderstood some minor point of the API. Turns out it's
entirely possible to just map the semaphore and be done with it. We
only need a flag to identify shared semaphores. This makes everything
a little bit easier.
In
On Wed, Nov 20, 2013 at 21:59, Stuart Henderson wrote:
graphics/ilmbase hangs during autoconf; it runs something close to this
The diff I previously posted seems to fix this. At least, I could
repro with a snapshot and now I can't reproduce after installing the
new library.
I also spotted one
On Wed, Nov 20, 2013 at 23:12, Stuart Henderson wrote:
On 2013/11/20 18:09, Ted Unangst wrote:
On Wed, Nov 20, 2013 at 21:59, Stuart Henderson wrote:
graphics/ilmbase hangs during autoconf; it runs something close to this
The diff I previously posted seems to fix this. At least, I could
Read the standard again and discovered some more missing features.
1. sem_open allows setting the value via a fourth argument. Fixed.
2. Multiple sem_open calls of the same path in the same process are
supposed to return the same pointer. Not the same semaphore, the same
pointer. This is mind
On Fri, Nov 22, 2013 at 10:09, Stuart Henderson wrote:
On 2013/11/22 07:25, Maxime Villard wrote:
If write() fails without EPIPE, d is decremented, and the function
keeps looping. If write() succeeds after several loops, d will be
negative, and the function will write from buf-XX.
When does
bad form, i think, to have a local variable shadow a global.
Index: kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.83
diff -u -p -r1.83 kern_clock.c
--- kern_clock.c8 Oct 2013 03:50:07 -
On Fri, Dec 06, 2013 at 20:47, Brad Smith wrote:
On Tue, Dec 03, 2013 at 06:48:11PM -0500, Brad Smith wrote:
An unused function in the UVM code. #if 0 it out for now.
uvm_map.c:171:14: error: unused function 'uvm_mapentry_freecmp'
[-Werror,-Wunused-function]
uvm_map.c:353:1: error: unused
On Fri, Dec 06, 2013 at 23:41, Brad Smith wrote:
The function isn't being called anywhere in the tree. You're missing the
point. The kernel builds with -Werror. I wouldn't care about these
warnings if it didn't.
-Wno-unused or whatever?
On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
This patch fixes problems in KDE4, that relies on sharing (process-shared)
semaphores via mmap(). This feature is used in the wild, so if we claim
that we support process-shared semaphores, we have to implement it, too.
This changes the
On Sat, Dec 07, 2013 at 21:32, Vadim Zhukov wrote:
2013/12/7 Ted Unangst t...@tedunangst.com:
On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
This patch fixes problems in KDE4, that relies on sharing (process-shared)
semaphores via mmap(). This feature is used in the wild, so if we claim
On Mon, Dec 09, 2013 at 19:49, Vadim Zhukov wrote:
So what's the decision?
Are there any objections still? If not, can I have a pair of okays?
KDE4 really needs a decision to be made: people already had apps
crashing without this diff, so I've put a dirty hack to stop KDE using
of
On Wed, Dec 11, 2013 at 11:12, Vadim Zhukov wrote:
If we go back to returning ENOMEM or whatever in sem_init, does that
fix KDE?
If we stop pretending we support shared unnamed semaphores, then, yes,
this will help KDE. But I cannot gurantee there will be no other
fallout. This needs a deep
I would like to be able to ask for an infinite number of updates in
top even in noninteractive mode. top -d 9 doesn't cut it.
Allow -1 to specify infinity.
Index: top.c
===
RCS file: /cvs/src/usr.bin/top/top.c,v
retrieving
On Sat, Dec 14, 2013 at 19:06, Maxime Villard wrote:
Hi,
I was reading linux_socket.c when I came across a bug in
linux_sendmsg().
At l.1252, if control == NULL, the function jumps to 'done' and 'level'
is checked while it hasn't been initialized. As 'control' is NULL,
copyout() tries to
On Sat, Dec 14, 2013 at 18:44, Mark Kettenis wrote:
Sorry to derail the train, but...
+#include sys/sysctl.h
This is no longer looking like the best header for the function
pointers to live in.
+ extern int perflevel;
This should probably live in a header too.
We don't have a
On Fri, Dec 13, 2013 at 19:42, Philip Guenther wrote:
+static __inline int
+process_is_multithreaded(struct process *pr)
+{
+ struct proc *p = TAILQ_FIRST(pr-ps_threads);
+ return (p != NULL TAILQ_NEXT(p, p_thr_link) != NULL);
This list will never be empty, so you can drop the p !=
On Sun, Dec 15, 2013 at 15:57, Philip Guenther wrote:
On Sat, Dec 14, 2013 at 10:34 AM, Ted Unangst t...@tedunangst.com wrote:
On Fri, Dec 13, 2013 at 19:42, Philip Guenther wrote:
+static __inline int
+process_is_multithreaded(struct process *pr)
+{
+ struct proc *p = TAILQ_FIRST(pr
101 - 200 of 1656 matches
Mail list logo
