On Wed, Mar 02, 2016 at 12:21:04PM +0100, Martin Pieuchot wrote:
> amd64 is the only arch that defines a function to set/get the value of
> the registers saved when entering ddb(4). This function is only needed
> because db_regs[] contains an offset relative to a trapframe rather than
> an address
Bob Beck said:
> This now starts to sounds sane, although the regress test needs to be
> named like paren-expansion-quotes not xxx-what-do-you-call this...
The test my previous diff failed was "xxx-what-do-you-call-this-1".
Should I rename it to "qouted-brace-expansion-1" and call my new test
"qou
This now starts to sounds sane, although the regress test needs to be
named like paren-expansion-quotes not xxx-what-do-you-call this...
On Wed, Mar 2, 2016 at 4:55 PM, Dmitrij D. Czarkoff wrote:
> Dmitrij D. Czarkoff said:
>> I recently came across a shell script that uses idiom
>>
>> var1=var
On Thu, Mar 03, 2016 at 09:38:25AM +1000, David Gwynne wrote:
>
> > On 2 Mar 2016, at 20:49, Patrick Wildt wrote:
> >
> > Hi,
> >
> > to allow FDT to be used on ARM I think we should move the FDT code from
> > socppc to sys/dev/fdt/. Opinions?
>
> i like this.
>
> does it need a directory of
Dmitrij D. Czarkoff said:
> I recently came across a shell script that uses idiom
>
> var1=var1
> var2=var2
> echo "${var1+($var2)}"
>
> ksh(1) doesn't like it:
>
> ksh: ${var1+($var2)}": bad substitution
>
> Meanwhile bash and dash just print:
>
> (var2)
>
> Apparently ksh tries to
> On 2 Mar 2016, at 20:49, Patrick Wildt wrote:
>
> Hi,
>
> to allow FDT to be used on ARM I think we should move the FDT code from
> socppc to sys/dev/fdt/. Opinions?
i like this.
does it need a directory of its own? could it be dev/ofw/fdt.c?
On Wed, 2 Mar 2016, Patrick Wildt wrote:
> Hi,
>
> to allow FDT to be used on ARM I think we should move the FDT code from
> socppc to sys/dev/fdt/. Opinions?
>
> Could someone test this diff for me?
Sure --- it compiles and boots on socppc (RB600A). I applied patch to HEAD
and removed the
Another piece of cruft...
option USER_LDT
Enable userland manipulation of per-process Local Descriptor Table (LDT)
entries; see i386_set_ldt(2) and the machdep.userldt sysctl(8). This
option is supported on the i386 architecture.
... for which there is consensus that it can g
The VOP_UNLOCK() function has a flags parameter, which is documented to
should be zero in most cases. It turns out that the flags argument is
zero for all ~200 callers in the tree. On a closer look it is revealed
that VOP_UNLOCK() uses lockmgr() for all filesystems that support
locking. The only l
On Tue, Mar 01, 2016 at 01:06:38PM +0100, Martin Pieuchot wrote:
> This is also dead code. ok?
nuke it.
>
> diff --git sys/arch/amd64/amd64/db_trace.c sys/arch/amd64/amd64/db_trace.c
> index 27fe24d..f0af6ec 100644
> --- sys/arch/amd64/amd64/db_trace.c
> +++ sys/arch/amd64/amd64/db_trace.c
> @@
On Tue, Mar 01, 2016 at 01:04:42PM +0100, Martin Pieuchot wrote:
> I'd like to remove this dead code because I'd like to unify to some
> extend the frame walking code between archs and this doesn't help.
>
> ok?
reads ok to me, go for it if it's not already in.
-ml
>
> diff --git sys/arch/amd6
This was first sent to w...@openbsd.org however that bounced, so I'm
sending it to tech@ instead.
> rejected by the server for the recipient domain openbsd.org by
> shear.ucar.edu. [192.43.244.163].
> The error that the other server returned was:
> 550 Invalid recipient
-Bryce
-- Forwar
On Wed, Mar 02, 2016 at 05:22:50PM +0100, Patrick Wildt wrote:
> Nice, glad to hear that!
>
> Looks like you're in a DDB panic? What happened? Can you
> do "show panic" in DDB?
Yes, it's in ddb. There is a trace in the previous message also, but here it is
a new one. This happens everytime when
On 28 February 2016 at 17:34, Martin Pieuchot wrote:
> On 28/02/16(Sun) 17:02, Mike Belopuhov wrote:
>> On 28 February 2016 at 14:38, Martin Pieuchot wrote:
>> > In order to dynamically instrument kernel functions, I plan to add
>> > breakpoints where a probe needs to be executed. Trap handlers
On Sat, Feb 27, 2016 at 04:45:09PM +0100, Matthieu Herrb wrote:
> On Sat, Feb 27, 2016 at 03:20:49PM +0100, Martin Pieuchot wrote:
> >
> > Instead of adding a "link" entry I would add a cloning route that will
> > generate it. The first diff below changes route(8) to not add a
> > RTF_GATEWAY fla
Here's an update to unbound.
The included diff *only* contains code parts, the full diff has 22K
lines of autoconf/makefile vomit. Do not use the included diff for
testing, use http://junkpile.org/unbound-1.5.8.diff.
Any comments, test reports, OKs?
>From the changelog:
+24 February 2016: Woute
On 17:19:39, 2.03.16, Martin Natano wrote:
> On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote:
> > kern_sched.c:
> > - remove unused functions
> > - mark static functions as static
>
> Functions shouldn't be static in the kernel. "In userland,
> functions local to one source module
I was reading kern_fork.c and noticed the oldpids array, which has a
size of 100. This means that when 'idx' in freepid() overflows, the
array index will be restarted at 95, not 99.
pid_t oldpids[100];
void
freepid(pid_t pid)
{
static uint32_t idx;
oldpids[idx++ % nitems(oldpids)]
Nice, glad to hear that!
Looks like you're in a DDB panic? What happened? Can you
do "show panic" in DDB?
Patrick
On Wed, Mar 02, 2016 at 01:08:55PM -0300, Daniel Bolgheroni wrote:
> On Sat, Feb 27, 2016 at 11:09:10PM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > the Allwinner A10 and A20 SoC i
On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote:
> kern_sched.c:
> - remove unused functions
> - mark static functions as static
Functions shouldn't be static in the kernel. "In userland,
functions local to one source module should be declared ‘static’. This
should not be done in k
On Sat, Feb 27, 2016 at 11:09:10PM +0100, Patrick Wildt wrote:
> Hi,
>
> the Allwinner A10 and A20 SoC include an EMAC, but it's only used in
> few devices like the Cubieboard. The A20, like the A31 and A80, contain
> a GMAC, which is a Synopsys Designware controller. This is commonly
> used on
kern_sched.c:
- remove unused functions
- mark static functions as static
proc.h:
- remove declarations
- convert spaces to tabs
- remove trailing empty line
Index: sys/kern/kern_sched.c
===
RCS file: /cvs/src/sys/kern/kern_sched.c,v
Hi,
currently we have a rather big list of bits that we remove and set in
the System Control Register. Those differ per processor, so not every
armv7/armv8 processor has the same bits, although they tend to be
rather similar.
I think we should only reset and set a few specific ones that we reall
On 2 March 2016 at 14:00, Jeremie Courreges-Anglas wrote:
>
> Router Renumbering was never supported, prefix ioctls were deprecated
> back in 2002, nobody uses them anymore out there. struct in6_prefix
> still uses a few bits from the prefix ioctl code, I've moved those bits
> to nd6.h. The last
I forgot a file in the diff, sorry.
diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
index 4fcc88a..8c8e0cf 100644
--- sys/arch/arm/arm/cpufunc.c
+++ sys/arch/arm/arm/cpufunc.c
@@ -1003,7 +1003,10 @@ set_cpufuncs()
(cputype & CPU_ID_CORTEX_A8_MASK) == CPU_ID_CORTEX_A8 |
Hi,
apparently AArch32 of ARMv8 is backwards compatible to ARMv7,
so we can basically run OpenBSD/armv7 on those new fancy chips.
Early on set_cpufuncs() is called and makes the kernel panic if
it can't find a setup routine for the processor it is running
on. This diff allows set_cpufuncs() to s
Router Renumbering was never supported, prefix ioctls were deprecated
back in 2002, nobody uses them anymore out there. struct in6_prefix
still uses a few bits from the prefix ioctl code, I've moved those bits
to nd6.h. The last (pointless) use of struct in6_prefixreq was in
rtadvd.
SIOCSIFADDR_
> On 2 Mar 2016, at 8:04 PM, Martin Pieuchot wrote:
>
> On 02/03/16(Wed) 10:33, Mike Belopuhov wrote:
>> On 2 March 2016 at 05:50, David Gwynne wrote:
>>> the max_link hdr is basically how much space to reserve before an
>>> ip packet for link headers, eg, ethernet.
>>>
>>> 16 bytes was a good
Jonathan Gray:
> You've used the wrong number for select, should be:
>
> linux/linux_syscall.h:#define LINUX_SYS_select142
Thank you! I'll fix that.
> diskprobe diff:
> exit diff:
Those look like harmless compiler churn.
--
Christian "naddy" Weisgerber na.
I have a router running this,
$ sysctl -n kern.version
OpenBSD 5.9 (GENERIC.MP) #1868: Mon Feb 1 20:02:36 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
$ ifconfig em1 hwfeatures | head -2
em1:
flags=18b43 mtu
1500
hwfeatures=36 hardmtu
16110
i.e. m
amd64 is the only arch that defines a function to set/get the value of
the registers saved when entering ddb(4). This function is only needed
because db_regs[] contains an offset relative to a trapframe rather than
an address.
I like the fact that db_regs[] contains an offset rather than an addre
On 02/03/16(Wed) 11:42, Mike Belopuhov wrote:
> On 1 March 2016 at 23:58, Martin Pieuchot wrote:
> > As explained previously I'm implementing an instrumentation system based
> > on ddb(4) and relying on breakpoints to execute kernel probes.
> >
> > For debugging purposes I need a way to dump the c
Or is it the other way around?
ok?
Index: ddb/db_elf.c
===
RCS file: /cvs/src/sys/ddb/db_elf.c,v
retrieving revision 1.19
diff -u -p -r1.19 db_elf.c
--- ddb/db_elf.c1 Mar 2016 21:32:02 - 1.19
+++ ddb/db_elf.c
Hi,
to allow FDT to be used on ARM I think we should move the FDT code from
socppc to sys/dev/fdt/. Opinions?
Could someone test this diff for me?
Patrick
diff --git sys/arch/socppc/conf/files.socppc sys/arch/socppc/conf/files.socppc
index d1fab5e..ade4e53 100644
--- sys/arch/socppc/conf/files
On 1 March 2016 at 23:58, Martin Pieuchot wrote:
> As explained previously I'm implementing an instrumentation system based
> on ddb(4) and relying on breakpoints to execute kernel probes.
>
> For debugging purposes I need a way to dump the content of the registers
> when a breakpoint-not-for-ddb(
On 02/03/16(Wed) 11:48, David Gwynne wrote:
> ive got a large reworking of vlan(4) to make vlan tx mpsafe, which
> affected mpw(4).
>
> the biggest effect was that it was no longer safe to traverse the
> interface parent hierarchy looking for vlan interfaces. however,
> from what i could tell from
On 02/03/16(Wed) 10:33, Mike Belopuhov wrote:
> On 2 March 2016 at 05:50, David Gwynne wrote:
> > the max_link hdr is basically how much space to reserve before an
> > ip packet for link headers, eg, ethernet.
> >
> > 16 bytes was a good choice when everything was just ip inside
> > ethernet, but
On 01/03/16(Tue) 16:27, Mike Larkin wrote:
> On Tue, Mar 01, 2016 at 11:58:57PM +0100, Martin Pieuchot wrote:
> > As explained previously I'm implementing an instrumentation system based
> > on ddb(4) and relying on breakpoints to execute kernel probes.
> >
> > For debugging purposes I need a way
> On 2 Mar 2016, at 7:33 PM, Mike Belopuhov wrote:
>
> On 2 March 2016 at 05:50, David Gwynne wrote:
>> the max_link hdr is basically how much space to reserve before an
>> ip packet for link headers, eg, ethernet.
>>
>> 16 bytes was a good choice when everything was just ip inside
>> ethernet
On 2 March 2016 at 05:50, David Gwynne wrote:
> the max_link hdr is basically how much space to reserve before an
> ip packet for link headers, eg, ethernet.
>
> 16 bytes was a good choice when everything was just ip inside
> ethernet, but now we deal with a bunch of encapsulations which blow
> th
40 matches
Mail list logo
