On Mon, Oct 6, 2014 at 5:08 AM, Dimitris Papastamos wrote:
> I am using select(2) on a FIFO fd and monitoring
> for readability. select(2) doesn't return after the writer
> exits.
>
> The same piece of code marks the fd as readable on Linux.
> Not sure which behaviour is correct though.
The Linu
>From RFC 3442:
Local Subnet Routes
In some cases more than one IP subnet may be configured on a link.
In such cases, a host whose IP address is in one IP subnet in the
link could communicate directly with a host whose IP address is in a
different IP subnet on the s
Patch below enables DWARF line decoding in ddb; e.g.,
ddb{0}> trace
Debugger() at Debugger+0x9 [../../../../arch/amd64/amd64/db_interface.c:405]
ddb_sysctl() at ddb_sysctl+0x1b4 [../../../../ddb/db_usrreq.c:104]
sys___sysctl() at sys___sysctl+0x216 [../../../../kern/kern_sysctl.c:229]
sy
On Thu, Jul 17, 2014 at 8:05 PM, patrick keshishian wrote:
> Silly even though, the description of lsearch says it will modify
> ("it shall be added at the end of") the table, for which "base
> argument points to the first element"?
Ah, I didn't pay close attention to the definition and assumed i
ation. The majority of our BSD code is OpenBSD so my preference
> would be to switch over as much as possible.
>
> On Jul 17, 2014 5:59 PM, "Matthew Dempsky" wrote:
>>
>> Hm, is there a practical consequence of this? Seems like it would
>> only affect applicati
Hm, is there a practical consequence of this? Seems like it would
only affect applications trying to store a reference to lsearch in a
function pointer of type "void (*)(const void *, void *, size_t *,
size_t, int (*)(const void *, const void *))"; do those exist?
On Thu, Jul 17, 2014 at 5:38 PM,
As the name suggests, remrunqueue(p) removes p from its run queue, and
I believe that makes TAILQ_FOREACH() here unsafe. Instead of actually
removing all threads from the processor, we'll only remove the first
from each of its run queues.
Diff below replaces TAILQ_FOREACH with the safe/idiomatic
Currently there's a lot of redundancy between dopselect() and
doppoll(). This diff cleans them up in the following ways:
- Better variable names. Instead of "rts", "ats", and "tts" they're
now called "deadline", "now", and "diff"; and "ncoll" is now
"selcookie". They're also all more
On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck wrote:
> The fundamental probelm with this Matthew - is that next time, if we
> do this, by the next release we will
> be chasing what features we have imported from 1.0.2g and 10.2.z, and
> 1.0.2.qq - where does it end?
It ends whenever it stops helping
On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck wrote:
> The OPENSSL_VERSION number is a guarantee for a certain version of the
> ABI. As we dont' provide that (in fact much
> of the ABI in LIbreSSL is "beyond" 1.0.1g, it is not accurate to use
> the old OPENSSL_VERSION. Essnentially this OPENSSL_VERSIO
On Thu, Jul 10, 2014 at 1:20 PM, Ted Unangst wrote:
> Thoughts?
Seems kind of hacky to me, but if it results in significant
performance improvements in real world uses, then I could be swayed
since it's not very intrusive either.
On Thu, Jul 10, 2014 at 1:17 PM, Kent R. Spillner wrote:
> If MAP_ANON is going to be the canonical value then shouldn't you
> change MAP_PRIVATE to MAP_ANON instead of MAP_ANONYMOUS in mmap.2?
No, Bl's "-width" option is used to specify how much padding should be
used to align the list entry tex
On Thu, Jul 10, 2014 at 12:34 PM, Jean-Philippe Ouellet
wrote:
> 2nd one should be mallocarray.
Doh, fixed. Thanks!
On Thu, Jul 10, 2014 at 02:42:34PM -0400, Ted Unangst wrote:
> On Thu, Jul 10, 2014 at 10:28, Matthew Dempsky wrote:
> > We've found a bunch of uses for reallocarray() in userland, and I
> > think the idiom is worth reusing in the kernel. There are enough
> > places wher
The Austin Group this morning accepted proposed wording to standardize
both MAP_ANON and MAP_ANONYMOUS, recognizing that neither was clearly
more popular than the other among applications, and that there's
precedent in POSIX for simply standardizing multiple spellings for a
feature when both are co
On Thu, Jul 10, 2014 at 10:28:35AM -0700, Matthew Dempsky wrote:
> +/*
> + * This is sqrt(SIZE_MAX+1), as s1*s2 <= SIZE_MAX
> + * if both s1 < MUL_NO_OVERFLOW and s2 < MUL_NO_OVERFLOW
> + */
> +#define MUL_NO_OVERFLOW (1UL << (sizeof(size_t) * 4))
> +
>
We've found a bunch of uses for reallocarray() in userland, and I
think the idiom is worth reusing in the kernel. There are enough
places where we do malloc(x * y) that I think it makes sense to add
mallocarray(x, y).
ok?
Index: share/man/man9/Makefile
===
On Mon, Jun 23, 2014 at 06:46:27AM -0700, Matthew Dempsky wrote:
> I did this mostly for fun / personal enlightenment, so I haven't put
> too much effort into polishing it yet.
I got some positive feedback about the direction of this diff, so
tonight I finally got around to polishing i
On Tue, Jul 8, 2014 at 3:51 PM, Philip Guenther wrote:
> * using atomics when we don't even have correct process-pending signals
> risks a solution that
>doesn't work when more than one pending set has to be examined.
I'll hold off on this until we have process-pending signals then.
Updated diff below with the following changes:
- p_sigmask is now volatile, per kettenis's request
- kern_fork.c's memcpy() for p_startcopy needs to cast away the
volatile now
- kettenis pointed out atomic_swap_uint() isn't safe to use in MI code
yet, so for now proc_sigsetmask() just relies o
On Tue, Jul 8, 2014 at 12:28 PM, Mark Kettenis wrote:
> With that explanation, this sounds a lot more reasonable.
Ah, good. :) Sorry, I should have mentioned up front the followup
steps I had planned and the rationale for taking this path.
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis wrote:
> I disagree with this diff. We should discourage the use of GNU
> extensions in our kernel. Therefore I think std=gnu99 would give the
> wrong signal.
Can you clarify your concern? Currently we're (implicitly) compiling
with -std=gnu89, wh
Diff below converts the kernel to build with -std=gnu99. (For
simplicity, I've only included amd64 for now, but I'll make the same
change to all kernel Makefiles if this is ok.)
The only incompatibility (that I'm aware of) is that ISO C99's inline
semantics differ slightly from GNU C89's historic
It's rare, but there *are* cases where a thread wants to sleep and
doesn't expect any wakeup() calls at all; e.g., nanosleep() and
sigsuspend(). In these cases, there's no point in requiring a valid
wait channel identifier or adding the thread to the sleep queue.
Diff below explicitly allows tsle
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis wrote:
>> Date: Mon, 7 Jul 2014 13:46:03 -0700
>> From: Matthew Dempsky
>>
>> p_sigmask is only modified by the owning thread from process context
>> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig
On Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot wrote:
> There was a previous attempt to mark sigpromask(2) as nolock but if I
> recall properly setting p_sigmask atomically is not enough and there's
> still a possible race in ptsignal().
>
> Have you looked into this function, is it safe now?
I
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
but it can be accessed anywhere (e.g., interrupts or threads on other
CPUs). Currently sys_sigprocmask() protects p_sigmask with splhigh(),
but that's not MP-sa
Recently guenther changed user credentials to be a per-process
resource, but kept a per-thread cache of credentials that get
refreshed at each system call entry. All of the get*[ug]id() system
calls simply access the thread cached credentials, and possibly
copyout() them if necessary, so they're s
I spent yesterday trying to really grok early pmap initialization on
amd64, and I noticed what I believe to be wasted physical pages of
memory:
1. In locore.S, we setup both an "identity" and an "actual" mapping
for the kernel, to help us bootstrap to executing in high memory.
Also, we reserve pag
According to the "Intel 64 and IA-32 Architectures Software
Developer's Manual", CPUID.8001H:EDX.Page1GB [bit 26] indicates
whether 1-GByte pages are supported with IA-32e paging.
I think the diff below adds support for identifying this feature in
dmesg, but my X201s is seemingly to old to sup
On Wed, Jul 2, 2014 at 5:16 PM, Matthew Dempsky wrote:
> +.if ${CC} == "clang"
> +CMACHFLAGS+= -ffreestanding
Sorry, Clang actually needs -fno-integrated-as too, otherwise the
integrated assembler complains about the bogus XYZZY instructions in
kern/genassym.sh.
Diff below allows building an amd64 kernel with "CC=clang make".
Some random notes:
1. A bunch of the -Wno-foo warnings are probably worth fixing, but
it's not a high priority for me at the moment.
2. -Wframe-larger-than= is the name modern GCC and Clang have adopted,
and it probably wouldn't hu
On Mon, Jun 30, 2014 at 2:47 PM, Ingo Schwarze wrote:
> so in a nutshell, mmap(2) was originally a BSD idea and first implemented
> in SunOS? And there is no doubt that *BSD always had MAP_ANON and never
> MAP_ANONYMOUS and that SunOS primarily defines MAP_ANON and MAP_ANONYMOUS
> only for "/* (s
udv_attach() and uvn_attach() are called directly, not via any generic
dispatch table mechanism, so there's no point in specifying that they
accept "void *" instead of the underlying types they actually expect.
ok?
Index: share/man/man9/uvm.9
==
On Mon, Jun 30, 2014 at 2:47 PM, Ingo Schwarze wrote:
>> mmap() "first appeared" in 4.1cBSD [mmap.2] and was scheduled for
>> inclusion in 4.2BSD (1983) [UVM thesis, p36], but didn't "actually
>> appear" until the 1993 4.4BSD release [UVM thesis, p36].
>
> At least MAP_ANON is definitely a lot old
On Mon, Jun 30, 2014 at 11:31 AM, Mark Kettenis wrote:
> Yes, I'm saying that this should affect POSIX's standardization.
> Solaris is where mmap(2) came from.
The full history is a bit more complicated though. From what I've
managed to uncover over the past few days so far:
mmap() "first appea
On Mon, Jun 30, 2014 at 10:42 AM, Mark Kettenis wrote:
> Solaris documents MAP_ANON in its man page, and defines MAP_ANONYMOUS
> as MAP_ANON for source compatibility.
Yep, but what about it? Are you suggesting that should affect POSIX's
standardization, or that we should do the same thing? I su
I filed an enhancement request with the Austin Group to standardize an
mmap() flag for mapping anonymous memory. I proposed standardizing
MAP_ANON, but the current proposal is to standardize MAP_ANONYMOUS
instead, as that seems to be the more common definition and usage:
http://austingroupbug
On Fri, Jun 27, 2014 at 02:46:01PM +0200, Mark Kettenis wrote:
> Losing the descriptions of the "no-op" flags is a bit unfortunate.
> Can you add those back?
Okay, restored them below. Also tested that kdump can handle this
change gracefully.
In this diff I've also moved MAP_FILE down to the leg
On Thu, Jun 26, 2014 at 12:28:18PM -0700, Matthew Dempsky wrote:
> I just reviewed our mmap(2) flags to compare them against Linux,
> FreeBSD, Solaris, and Darwin's flags. Of the flags listed below, none
> of them are specified by POSIX, and none of them do anything
> inter
I just reviewed our mmap(2) flags to compare them against Linux,
FreeBSD, Solaris, and Darwin's flags. Of the flags listed below, none
of them are specified by POSIX, and none of them do anything
interesting on OpenBSD: MAP_COPY just gets rewritten to MAP_PRIVATE,
and the rest are silently ignored
On Tue, Jun 24, 2014 at 11:04:10AM -0700, Matthew Dempsky wrote:
> SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of
> the underlying mapped file.
Generating SIGBUS for this case has proven controversial due to
concern that this is Linux invented behavior and not comp
POSIX specifies these error cases for memory faults:
SIGSEGV/SEGV_MAPERR: Accessing an unmapped page.
SIGSEGV/SEGV_ACCERR: Reading from a non-readable or writing to a
non-writable page.
SIGBUS/BUS_ADRERR: Accessing a mapped page that exceeds the end of
the underlying mapped file.
I a
On Mon, Jun 23, 2014 at 9:59 AM, Miod Vallat wrote:
> I love this. I have verified that kernels for all our gcc4 platforms
> still build with this diff.
Awesome! I also heard back from guenther@ that he completed an i386
base build without warnings too.
Do we want to test this any further (e.g.
===
RCS file: ddb/db_elf_dwarf.c
diff -N ddb/db_elf_dwarf.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ddb/db_elf_dwarf.c 23 Jun 2014 13:37:34 -
@@ -0,0 +1,404 @@
+/* $OpenBSD$*/
+/*
+ * Copyright (c) 2014 Matthew Dempsky
+ *
+ * Permission to use, copy, modify
I suspect procfs is only enabled on i386 because that's the only arch
with compat_linux support? If so, anyone who relies on compat_linux
support should be sure to test and report back if they have problems.
On Sun, Jun 22, 2014 at 2:22 PM, Philip Guenther wrote:
> If you're currently using proc
GCC supports an "aligned" attribute to specify a minimum alignment for
types/objects. However, if an object is allocated on the stack and
its alignment exceeds the "preferred stack boundary", then GCC 4.2
silently ignores the alignment.
This bit us 4 years ago when the SCSI stack started allocati
Reading through exec_elf.c, I just noticed the uninitialized bdiff
variable myself, and remembered this thread.
Tangentially, the code for worrying about zero-filling the last page
is overzealous. We only need to zero-fill the page if memsz > filesz
(accounting for alignment and page boundaries).
On Sun, Jun 15, 2014 at 1:20 PM, Jean-Philippe Ouellet
wrote:
> Those 4 memcpy()s are copying the things referenced by the old
> filedesc to the new one. The things being copied are file*s,
> not file**s. They're the same size anyway, but still...
Technically, C99 grants implementations leeway t
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck wrote:
> Would a rwlock do? The sender and recver operate asynchronously, so
> the sender needs to hold a lock while sending and release it when
> asleep, but it can't be a mutex as the send operation may sleep, so I
> used requ.ready as the lock, but
On Wed, May 14, 2014 at 4:58 AM, Jérémie Courrèges-Anglas
wrote:
> if (cmsg->cmsg_len == CMSG_LEN(sizeof(int)) &&
> cmsg->cmsg_level == SOL_SOCKET &&
> cmsg->cmsg_type == SCM_RIGHTS) {
>
On Mon, May 5, 2014 at 3:56 PM, Alexander Hall wrote:
> I believe a similar situation could appear with not explicitly initialized
> global or static declarations, e.g. in
> sbin/fsirand/fsirand.c:
>
> fsirand(char *device)
> {
> ...
> static char *inodebuf;
This is safe too: C re
On Sun, May 4, 2014 at 8:26 PM, Jean-Philippe Ouellet
wrote:
> On Sun, May 04, 2014 at 11:30:40PM +0200, Alexander Hall wrote:
>> NULL theoretically could be != 0
>
> Umm... short of something like:
> #undef NULL
> #define NULL "I'm silly and want to break everything"
> or something, I don
On Tue, Apr 22, 2014 at 2:43 PM, Stefan Sperling wrote:
> Your regression test has at least one bug ('bad' is never initialised).
It's perhaps bad *style* to not explicitly initialize it, but C99
6.7.8p10 says "If an object that has static storage duration is not
initialized explicitly, then: [..
On Tue, Dec 3, 2013 at 4:15 PM, Matthew Dempsky wrote:
> The patch below extends dhclient to mimic this logic from ISC DHCP's
> linux script:
>
> if [ "x$new_subnet_mask" = "x255.255.255.255" ] ; then
> route add -host $router dev $in
On Wed, Dec 04, 2013 at 02:10:21PM -0500, Kenneth R Westerback wrote:
> No, that was my point. i.e. don't avoid adding the route when given
> a /32 address just because class static routes are also present.
I think there might be a misunderstanding, so let me back up and try
to clarify. :)
Comput
On Tue, Dec 03, 2013 at 11:48:05PM -0500, Kenneth Westerback wrote:
> Rfc 3442 is what I referred to.
I don't think RFC 3442 discusses what to do with /32 IP address
assignments though?
Anyway, below is a revised diff that does the same direct-route magic
for all gateway IPs, not just the default
On Tue, Dec 3, 2013 at 5:55 PM, Kenneth R Westerback
wrote:
> Located here, the addition of the 255.255.255.255 route is not done in the
> presence of DHO_CLASSLESS_STATIC_ROUTES. As I recall only DHO_ROUTERS and
> DHO_STATIC_ROUTES are incompatible with DHO_CLASSLESS_STATIC_ROUTES. So
> we may wa
The patch below extends dhclient to mimic this logic from ISC DHCP's
linux script:
if [ "x$new_subnet_mask" = "x255.255.255.255" ] ; then
route add -host $router dev $interface
fi
route add default gw $router $metric_arg dev $interface
With this change, dhclient
On Tue, Dec 3, 2013 at 1:39 PM, Philip Guenther wrote:
> What problem does the casts solve?
I wasn't sure if people might be calling FD_COPY()/FD_ZERO() with
void* or char* typed arguments (or other custom sized types). If we
can assume they'll only pass fd_set* arguments, then they could be
don
On Tue, Dec 3, 2013 at 1:55 PM, Christian Weisgerber wrote:
> +#if __BSD_VISIBLE
> +#defineFD_COPY(f, t) (void)(*(t) = *(f))
> +#endif
> +#defineFD_ZERO(p) do \
> + fd_set *_p = (p); \
> + __size_t _n = _
On Tue, Dec 3, 2013 at 12:37 PM, Philip Guenther wrote:
> needs to stay until FD_ZERO() and FD_COPY() are changed to
> not use memset()/memcpy().
Good point.
Would something like this work?
#define FD_COPY(f, t) (*(fd_set *)(t) = *(const fd_set *)(f))
static const fd_set __fd_zero_set;
#defi
On Tue, Dec 3, 2013 at 12:08 PM, Christian Weisgerber
wrote:
> ok?
ok matthew
> +.Fd #include
Worth using .In instead while you're at it?
On Wed, Aug 28, 2013 at 5:54 AM, Maxime Villard wrote:
> + /* Ensure interp is a valid, NUL-terminated string */
> + for (n = 0; n < pp->p_filesz; n++) {
> + if (interp[n] == '\0')
> + b
Committed. Thanks Simon!
On Tue, Jul 9, 2013 at 10:21 AM, Jason McIntyre wrote:
> On Tue, Jul 09, 2013 at 07:07:03PM +0200, Marc Espie wrote:
>> On Tue, Jul 09, 2013 at 06:09:02PM +0200, Simon Kuhnle wrote:
>> > On Tue, Jul 09, 2013 at 12:29:10AM -0700, Matthew Dempsky wrote:
On Tue, Jul 9, 2013 at 12:22 AM, Marc Espie wrote:
> Starting
> .Ox 5.4 ,
> all supported platforms use it as the native binary file format.
I think "Starting *with* .Ox 5.4, ..." but otherwise ok matthew.
Might be nice to mention that 5.4 'was' the first release that used
ELF on all platforms?
On Mon, Jul 8, 2013 at 11:16 PM, Simon Kuhnle wrote:
> With VAX being an ELF platform, this is no longer true, is it?
>
> Regards
> Simon
>
> Index: elf.5
> ==
On Mon, Jul 8, 2013 at 2:06 AM, Maxime Villard wrote:
> Ah, yes. I didn't know.
For what it's worth, this is specified in C99 §6.7.8 (Initializaton)
paragraph 10:
"If an object that has static storage duration is not initialized
explicitly, then:
— if it has pointer type, it is initialized to a
On Tue, Jun 18, 2013 at 11:04 AM, wrote:
> Please, What is the difference between 'fsck' and 'fsck_ffs' command?
fsck detects the filesystem on disk and runs the appropriate
fsck_${FILESYSTEM} utility automatically.
Diff below fixes our wcsto{f,d,ld}() implementations in the following
ways:
- It handles "inf", "infinity", "nan", and "nan(whatever)" forms.
- It rejects strings like "-" and "+" by excluding the sign
characters when checking that we've actually matched some characters
to parse.
- Because
Nice, LGTM. :)
ok matthew
On Fri, May 31, 2013 at 5:43 PM, Stefan Sperling wrote:
> Yes. Conversion currently depends on the GNU iconv port.
> If iconv existed in base we could use just the UTF-8 source files.
Hmm, I see. In that case, I guess committing converted files makes sense.
In your man page diff, you should mak
On Fri, May 31, 2013 at 5:19 PM, Stefan Sperling wrote:
> Existing lib/libc/nls/*.msg files are renamed to the names shown in
> the libc/Makefile part of the diff, and new ones are added to support
> the UTF-8 locale (converted from the existing .msg files with iconv).
> I'm not including this cha
On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov wrote:
> my intention here is very simple: there's a way you should call
> device_lookup and everyone has to fulfill it's part of the contract.
> all our devices do, vscsi doesn't. what's the reason for it to be
> one of a kind?
I'm ok with adding
On Tue, Apr 9, 2013 at 11:10 AM, Stefan Sperling wrote:
>> + size_t lus1 = strlen(us1);
>> + size_t lus2 = strlen(us2);
These strlen() calls are also wrong, because they could read past the
n bytes allowed for strncasecmp().
> It seems strncasecmp() cannot return errors a
On Fri, Apr 5, 2013 at 3:26 PM, Ted Unangst wrote:
> Index: sys/sysctl.h
> ===
> RCS file: /cvs/src/sys/sys/sysctl.h,v
> retrieving revision 1.131
> diff -u -p -r1.131 sysctl.h
> --- sys/sysctl.h24 Mar 2013 00:09:31 -
On Wed, Mar 27, 2013 at 4:15 PM, Nicholas Marriott
wrote:
> Sure, that actually looks to be what other shells do anyhow.
That looks ok to me.
Which shells did you check, out of curiosity? On Goobuntu, both bash
and dash give SIGFPE too actually.
Checking POSIX, I notice that it requires that s
On Wed, Mar 27, 2013 at 3:56 PM, Nicholas Marriott
wrote:
> case O_DIV:
> case O_DIVASN:
> + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> + evalerr(es, ET_STR, "can't represent result");
>
Committed, thanks!
On Thu, Jan 24, 2013 at 9:57 AM, Maxime Villard wrote:
> Hum here, if vp->v_type != VLNK, auio is untouched, but before returning
> we use auio.uio_resid, which is not initialized. Is it?
>
Nice catch. We should probably move the *retval assignment up just after
the VOP_READLINK() call, since t
On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst wrote:
> This adds a -T portnum option to ping. I haven't polished the output
> because I'm not sure if this is desirable or not, but I found it
> useful. If it's not a "hell no, never in base" I can finish it up some.
Is there precedent for having
This diff is super hacky and just mailed out for proof-of-concept, but
it's something that's been handy for me while hacking on ld.so.
Basically before installing a new version of ld.so, it just runs a
simple test program to double check that ld.so isn't completely hosed.
There's plenty of issues
The diff below changes GCC's default behavior to -fstack-protector-all
(i.e., add stack protection code to every function instead of just
some based on heuristics), but you can still revert to the heuristic
behavior by passing -fstack-protector on the command line.
Beware this diff has only receiv
On Wed, Aug 29, 2012 at 11:16 AM, Matthew Dempsky wrote:
> First, make sure you're using a reasonably up to date snapshot.
> You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
At least two people have commented that the snapshots they downloaded
do
11:16:16AM -0700, Matthew Dempsky wrote:
> First, make sure you're using a reasonably up to date snapshot.
> You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
>
> Next, apply the patch below to GCC, recompile, and install:
>
> $ cd /usr/src/
First, make sure you're using a reasonably up to date snapshot.
You're up to date if "nm /usr/lib/crtbegin.o" mentions __guard_local.
Next, apply the patch below to GCC, recompile, and install:
$ cd /usr/src/gnu/gcc/gcc
$ patch < /path/to/diff
$ cd /usr/src/gnu/usr.bin/cc
$ make depend &&
On Sun, Aug 26, 2012 at 10:28 AM, Chris Bennett
wrote:
> I have done a fresh checkout of -current src, but I still get:
>
> # ld --verbose | grep randomdata
> PROVIDE (__openbsd_randomdata_start = .);
> .openbsd.randomdata :
> *(.openbsd.randomdata .openbsd.randomdata.*)
> PROVIDE (_
A few days ago I committed a change to binutils to add support for
.openbsd.randomdata sections and then later converted libc to make use
of them. It seems that at least armish is not happy with libc
compiled using an out-of-date binutils, so if you're following from
source be careful to update bi
On Wed, Aug 22, 2012 at 8:59 AM, Philip Guenther wrote:
> So, you can use 'div' as the name of a object variable without
> concern...if you're in a standard conforming compilation.
And as long as it's not an object variable of a function pointer type
that you later invoke like "div(foo)" rather t
This reminds me...
On Wed, Aug 15, 2012 at 8:02 AM, Ted Unangst wrote:
> 0x, /* counter_mask (24 bits) */
... this comment has been bugging me for a while. I'm pretty sure it
should be "32 bits". Seems like a bad copy/paste from acpitimer.c.
While I recognize there's some precedence in the tree for it already,
this seems ugly to me. Is there a reason different programs/libraries
need different diagnostic flags? Why doesn't this belong in
bsd.own.mk or mk.conf?
On Wed, Jul 25, 2012 at 8:01 AM, Todd T. Fries wrote:
> There is a paper entitled "Secure Deletion of Data from Magnetic and
> Solid-State Memory"
> from the Sixth (6th) Annual USENiX Security Symposium that talks about this.
My reading of that paper and the Wikipedia article suggests it's not
v
On Thu, Jul 12, 2012 at 9:48 AM, Paul Irofti wrote:
> + if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_GLK", 0, NULL, &res))
> + sc->sc_glk = 0;
> + if (res.type != AML_OBJTYPE_INTEGER)
> + sc->sc_glk = 0;
> + else
> + sc->sc_glk = res.v
On Wed, Jul 11, 2012 at 12:40 PM, Jiri B wrote:
> Like this one...
>
> mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 2 int 17
> scsibus1 at mpi0: 16 targets, initiator 7
> sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed
> sd0: 61440MB, 512 bytes/sector, 125829120 sector
On Wed, Jul 11, 2012 at 6:01 AM, Jiri B wrote:
> Or even better, it would be much important to make OpenBSD to see added
> disks without reboot (it means rescanning the bus).
I don't understand what you're referring to here. OpenBSD already
handles hotplugged disks in quite a few cases; e.g., US
On Wed, Jul 11, 2012 at 8:20 AM, Kenneth R Westerback
wrote:
> And we dream of the day when wd and vnd attach as scsi too!
Stop peaking at my dev box's src tree!!
On Wed, Jul 11, 2012 at 8:28 AM, Stefan Fritsch wrote:
> There is a virtio-scsi device, too, but this is only supported in very
> recent versions of qemu. To attach the simpler virtio-block device as scsi,
> the driver would have to emulate the scsi commands. Is there some generic
> infrastructure
On Tue, Jul 10, 2012 at 11:49 AM, Han Boetes wrote:
> I found this mistake in the stat manpage:
Not a mistake; see /usr/include/sys/stat.h.
It looks like arm and sh are broken too. I've added a regress test to
/usr/src/regress/sys/kern/sigpending if anyone wants to try tackling
one or more of these broken implementations.
On Thu, Jun 28, 2012 at 5:10 PM, Matthew Dempsky wrote:
> On Thu, Jun 28, 2012 at 5:09 PM, Matthew
On Thu, Jun 28, 2012 at 5:09 PM, Matthew Dempsky wrote:
> So the sigpending() system call returns the pending signals as an int
> value via register, but then the libc stub is supposed to take care of
> storing this as appropriate.
>
> If you look at libc/arch/amd64/sys/sigreturn.S
1 - 100 of 268 matches
Mail list logo
