On Mon, Oct 6, 2014 at 5:08 AM, Dimitris Papastamos s...@2f30.org 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.
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
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]
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,
is OpenBSD so my preference
would be to switch over as much as possible.
On Jul 17, 2014 5:59 PM, Matthew Dempsky matt...@dempsky.org wrote:
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
On Thu, Jul 17, 2014 at 8:05 PM, patrick keshishian pkesh...@gmail.com 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
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
On Fri, Jul 11, 2014 at 3:41 PM, Bob Beck b...@obtuse.com 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
On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck b...@obtuse.com 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
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 it some more
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 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))
+
+void *
+mallocarray(unsigned long nmemb, unsigned
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
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 where we do malloc(x * y) that I
On Thu, Jul 10, 2014 at 12:34 PM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
2nd one should be mallocarray.
Doh, fixed. Thanks!
On Thu, Jul 10, 2014 at 1:17 PM, Kent R. Spillner kspill...@acm.org 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
On Thu, Jul 10, 2014 at 1:20 PM, Ted Unangst t...@tedunangst.com 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 Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot mpieuc...@nolizard.org 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,
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 7 Jul 2014 13:46:03 -0700
From: Matthew Dempsky matt...@dempsky.org
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig
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
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
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis mark.kette...@xs4all.nl 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)
On Tue, Jul 8, 2014 at 12:28 PM, Mark Kettenis mark.kette...@xs4all.nl 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.
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
On Tue, Jul 8, 2014 at 3:51 PM, Philip Guenther guent...@gmail.com 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
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
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
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 pages
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
On Wed, Jul 2, 2014 at 5:16 PM, Matthew Dempsky matt...@dempsky.org 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.
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
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 schwa...@usta.de 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
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:
On Mon, Jun 30, 2014 at 10:42 AM, Mark Kettenis mark.kette...@xs4all.nl 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
On Mon, Jun 30, 2014 at 11:31 AM, Mark Kettenis mark.kette...@xs4all.nl 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
On Mon, Jun 30, 2014 at 2:47 PM, Ingo Schwarze schwa...@usta.de 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
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 legacy
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
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
interesting on OpenBSD: MAP_COPY
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
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 compatible
/db_elf_dwarf.c 23 Jun 2014 13:37:34 -
@@ -0,0 +1,404 @@
+/* $OpenBSD$*/
+/*
+ * Copyright (c) 2014 Matthew Dempsky matt...@dempsky.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided
On Mon, Jun 23, 2014 at 9:59 AM, Miod Vallat m...@online.fr 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
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 guent...@gmail.com wrote:
If you're
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 allocating
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
jean-phili...@ouellet.biz 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
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck strake...@gmail.com 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
On Wed, May 14, 2014 at 4:58 AM, Jérémie Courrèges-Anglas
j...@wxcvbn.org 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 alexan...@beard.se 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
On Tue, Apr 22, 2014 at 2:43 PM, Stefan Sperling s...@openbsd.org 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
On Tue, Dec 3, 2013 at 4:15 PM, Matthew Dempsky matt...@dempsky.org 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 $interface
fi
route
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 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. :)
Compute
On Tue, Dec 3, 2013 at 12:08 PM, Christian Weisgerber
na...@mips.inka.de wrote:
ok?
ok matthew
+.Fd #include sys/select.h
Worth using .In instead while you're at it?
On Tue, Dec 3, 2013 at 12:37 PM, Philip Guenther guent...@gmail.com wrote:
string.h 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
On Tue, Dec 3, 2013 at 1:55 PM, Christian Weisgerber na...@mips.inka.de wrote:
+#if __BSD_VISIBLE
+#defineFD_COPY(f, t) (void)(*(t) = *(f))
+#endif
+#defineFD_ZERO(p) do \
+ fd_set *_p = (p); \
+
On Tue, Dec 3, 2013 at 1:39 PM, Philip Guenther guent...@gmail.com 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
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 is
On Tue, Dec 3, 2013 at 5:55 PM, Kenneth R Westerback
kwesterb...@rogers.com 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
On Wed, Aug 28, 2013 at 5:54 AM, Maxime Villard m...@m00nbsd.net wrote:
+ /* Ensure interp is a valid, NUL-terminated string */
+ for (n = 0; n pp-p_filesz; n++) {
+ if (interp[n] == '\0')
+
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 si...@blarzwurst.de wrote:
With VAX being an ELF platform, this is no longer true, is it?
Regards
Simon
Index: elf.5
On Tue, Jul 9, 2013 at 12:22 AM, Marc Espie es...@nerim.net 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.
Committed. Thanks Simon!
On Tue, Jul 9, 2013 at 10:21 AM, Jason McIntyre j...@kerhand.co.uk 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 Mon, Jul 8, 2013 at 2:06 AM, Maxime Villard rusty...@gmx.fr 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
On Tue, Jun 18, 2013 at 11:04 AM, laborat...@cpnetserver.net 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.
On Fri, May 31, 2013 at 5:19 PM, Stefan Sperling s...@openbsd.org 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
On Fri, May 31, 2013 at 5:43 PM, Stefan Sperling s...@openbsd.org 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,
On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov m...@belopuhov.com 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
On Tue, Apr 9, 2013 at 11:10 AM, Stefan Sperling s...@openbsd.org 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
On Fri, Apr 5, 2013 at 3:26 PM, Ted Unangst t...@tedunangst.com 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
On Wed, Mar 27, 2013 at 3:56 PM, Nicholas Marriott
nicholas.marri...@gmail.com 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);
On Wed, Mar 27, 2013 at 4:15 PM, Nicholas Marriott
nicholas.marri...@gmail.com 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
Committed, thanks!
On Thu, Jan 24, 2013 at 9:57 AM, Maxime Villard rusty...@gmx.fr 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()
On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst t...@tedunangst.com 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
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
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
-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/gnu/gcc/gcc
$ patch /path/to/diff
$ cd /usr/src
On Wed, Aug 29, 2012 at 11:16 AM, Matthew Dempsky matt...@dempsky.org 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
don't have
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
This reminds me...
On Wed, Aug 15, 2012 at 8:02 AM, Ted Unangst t...@tedunangst.com 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 Thu, Jul 12, 2012 at 9:48 AM, Paul Irofti p...@irofti.net 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 =
On Wed, Jul 11, 2012 at 8:28 AM, Stefan Fritsch s...@sfritsch.de 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
On Wed, Jul 11, 2012 at 8:20 AM, Kenneth R Westerback
kwesterb...@rogers.com 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 6:01 AM, Jiri B ji...@devio.us 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
On Wed, Jul 11, 2012 at 12:40 PM, Jiri B ji...@devio.us 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: VMware, Virtual disk, 1.0 SCSI2 0/direct fixed
sd0: 61440MB,
On Tue, Jul 10, 2012 at 11:49 AM, Han Boetes h...@boetes.org 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 matt...@dempsky.org wrote:
On Thu, Jun 28, 2012 at 5:09 PM
On Tue, Jun 19, 2012 at 1:35 PM, Vincent Bernat ber...@luffy.cx wrote:
Maybe it would be better to implement standard MIB like
HOST-RESOURCES-MIB.
snmpd already supports HOST-RESOURCES-MIB.
Seth, does your diff expose any new information that's not already
available via snmpd? If not, I think
[+joel]
On Tue, Jun 19, 2012 at 2:11 PM, Seth Wright s...@crosse.org wrote:
I kind of thought the UCD-SNMP-MIB was fairly standard and/or
widespread, but perhaps not?
HOST-RESOURCES-MIB is an RFC standard, which I assume gives it more
stature than UCD-SNMP-MIB, but I honestly haven't used SNMP
I'd like to monitor disk IO on my workstation, but snmpd doesn't
currently export hw.diskstats as far as I can tell. I found net-snmp
supports UCD-DISKIO-MIB and it's not too complex, so I went ahead and
coded up an implementation.
It's been a while since I've touched SNMP and/or snmpd, but it
Are you missing the header bits for linux_statfs64? I don't see where
it's defined.
+ /*
+* Convert BSD filesystem names to Linux filesystem type numbers
+* where possible. Linux statfs uses a value of -1 to indicate
+* an unsupported field.
+*/
+
On Tue, May 22, 2012 at 9:42 AM, Paul Irofti p...@irofti.net wrote:
+ /*
+* Convert BSD filesystem names to Linux filesystem type numbers
+* where possible. Linux statfs uses a value of -1 to indicate
+* an unsupported field.
+*/
+ if
On Fri, May 18, 2012 at 4:27 PM, Juan Francisco Cantero Hurtado
i...@juanfra.info wrote:
In short. Can someone say me what are these values?. I don't want a
master class, just a link or a bit of documentation is sufficient.
Are you just trying to swap caps and ctrl at the console? If so, just
On Thu, Mar 15, 2012 at 3:19 AM, Marc Espie es...@nerim.net wrote:
#define __glibcxx_max(T) \
- (__glibcxx_signed (T) ? ((T)1 __glibcxx_digits (T)) - 1 : ~(T)0)
+ (__glibcxx_signed (T) ? \
+ (T)1 (__glibcxx_digits (T) - 1)) - 1) 1) + 1) : ~(T)0)
+
How about (T)(((unsigned T)1
I'm pretty sure unsigned int is never a signed type.
Oh even if it's not signed that ternary branch will still be in code. I
see. Hm.
On May 10, 2012 9:23 AM, Matthew Dempsky matt...@dempsky.org wrote:
1 - 100 of 217 matches
Mail list logo
