Re: Kill db_x86_64_regop()

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

Re: ksh: variable substitution in double quoted string

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

Re: ksh: variable substitution in double quoted string

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

Re: fdt: move code from socppc to sys/dev/fdt/

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

Re: ksh: variable substitution in double quoted string

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

Re: fdt: move code from socppc to sys/dev/fdt/

> 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?

Re: fdt: move code from socppc to sys/dev/fdt/

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

remove VOP_UNLOCK() flags

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

Re: Kill db_find_trace_symbols()

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 > @@

Re: db_sym_numargs() is always false

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

faq15.html

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 --

Re: arm: support Allwinner A20 Ethernet

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

Re: x86 BPTTRAP

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

Re: /32 routes don't stick

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

unbound 1.5.8

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:

Re: kern_sched.c: unused functions

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

Re: arm: support Allwinner A20 Ethernet

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: unused functions

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:

arm: only (re)set specific bits in sctlr

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

Re: Remove more netinet6 cruft

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 >

Re: arm: allow Cortex-A53/A57/A72 on armv7

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

arm: allow Cortex-A53/A57/A72 on armv7

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

Remove more netinet6 cruft

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.

Re: bump the max_linkhdr size from 16 bytes to 64

> 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,

Re: zaurus: disentangle zboot from compat/linux

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

Kill db_x86_64_regop()

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

Re: ddb: show regs with address

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

Merge db_elf_sym_values() into db_symbol_values()

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

fdt: move code from socppc to sys/dev/fdt/

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 ---

Re: ddb: show regs with address

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

Re: mpw(4) vlan handling

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

Re: bump the max_linkhdr size from 16 bytes to 64

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

Re: ddb: show regs with address

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

Re: bump the max_linkhdr size from 16 bytes to 64

> 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

Re: bump the max_linkhdr size from 16 bytes to 64

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