Re: CVS commit: src/lib/libc_fp

[Matt Thomas]

> On Jul 14, 2016, at 11:39 PM, David Holland 
>  wrote:
> 
> Can you call this MTC1_HAZARD like the MFC0_HAZARD that got added
> recently elsewhere? It's a pipeline hazard and not a synchronization
> (which to me at least indicates some form of handshake) and it's also
> specific to mtc1/dmtc1.

That's reasonable.

> (also while this code appears to currently be 64-bit only, in the long
> run the condition is wrong...)

Well, O32 handles FP emulation.

So this is really for N32/N64 since they default to softfloat.  They use
64-bit registers so I don't see the point.

Re: CVS commit: src/sys/kern

[Matt Thomas]

 On Aug 7, 2015, at 4:05 PM, matthew green m...@eterna.com.au wrote:
 
 linux ld.so has an entry point, for instance.  IIRC, it's related
 to how their ldd(1) works.

As does our ld.elf_so.1

Re: CVS commit: src/sys/kern

[Matt Thomas]

 On Aug 5, 2015, at 11:52 PM, Martin Husemann mar...@netbsd.org wrote:
 
 When I first ran into the exec a .so path I've been told it is a feature
 and exists on purpose (though our native in-tree libs do not make use of it).

It's also used for PIE which are usually DYN instead of EXEC.

Re: CVS commit: src/sys/arch/arm/broadcom

[Matt Thomas]

 On Jul 25, 2015, at 1:43 AM, Nick Hudson sk...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: skrll
 Date: Sat Jul 25 08:43:41 UTC 2015
 
 Modified Files:
   src/sys/arch/arm/broadcom: bcm2835_intr.c
 
 Log Message:
 IPIs should be IPL_HIGH according to rmind@
 
 Fix bcm2836mp_pic_{un,}block_irqs to handle timer AND mailbox interrupts
 if they're both passed.  Thanks to nat@ for finding this.
 
 Sprinkle some KASSERTs

It depends on the IPI.  IPI_AST doesn't need to be IPI_HIGH since all it does
is get the target cpu out of usermode.

Re: CVS commit: src/distrib/zaurus/ramdisk

[Matt Thomas]

 On Jul 17, 2015, at 12:32 PM, Martin Husemann mar...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: martin
 Date: Fri Jul 17 19:32:48 UTC 2015
 
 Modified Files:
   src/distrib/zaurus/ramdisk: Makefile
 
 Log Message:
 Bump ram disk image size slightly

That was not needed.  I successfully built the
ramdisk with the current settings.

Re: CVS commit: src/usr.sbin/postinstall

[Matt Thomas]

 On Jul 1, 2015, at 5:52 AM, Martin Husemann mar...@duskware.de wrote:
 
 On Wed, Jul 01, 2015 at 10:49:51PM +1000, matthew green wrote:
 wait, we do what?  this won't work for r/o src, right?
 
 I guess not (though in most cases you probably will use the sets mode
 of postinstall, which is unaffected).
 
 As I said, we should come up with something better (in
 src/etc/mtree/Makefile), this is just damage limitation and should go
 away after a real fix.

It does seems to get an objdir:

$ ls ../amd64/obj/etc/mtree/NetBSD.dist
NetBSD.dist  NetBSD.dist.tmp  
NetBSD.dist.compat   NetBSD.dist.xcompat  

So what is the issue?

Re: CVS commit: src/usr.sbin/postinstall

[Matt Thomas]

 On Jul 1, 2015, at 5:52 AM, Martin Husemann mar...@duskware.de wrote:
 
 On Wed, Jul 01, 2015 at 10:49:51PM +1000, matthew green wrote:
 wait, we do what?  this won't work for r/o src, right?
 
 I guess not (though in most cases you probably will use the sets mode
 of postinstall, which is unaffected).
 
 As I said, we should come up with something better (in
 src/etc/mtree/Makefile), this is just damage limitation and should go
 away after a real fix.

Doesn’t etc/mtree get an obj dir?

Re: CVS commit: src/common/lib/libc/string

[Matt Thomas]

 On May 29, 2015, at 12:46 PM, Joerg Sonnenberger jo...@britannica.bec.de 
 wrote:
 
 On Fri, May 29, 2015 at 07:39:41PM +, Matt Thomas wrote:
 Module Name: src
 Committed By:matt
 Date:Fri May 29 19:39:41 UTC 2015
 
 Modified Files:
  src/common/lib/libc/string: popcount32.c popcount64.c
 
 Log Message:
 Don't compile if there is a macro of the same name.
 
 At least for libc, we definitely want to include the symbols.

which does happen since C doesn’t include libkern.h which defines them.

Re: CVS commit: src/distrib/utils/embedded/conf

[Matt Thomas]

 On May 22, 2015, at 11:07 AM, Christos Zoulas chris...@astron.com wrote:
 
 In article 20150522011822.807e...@cvs.netbsd.org,
 Jared D. McNeill source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:jmcneill
 Date:Fri May 22 01:18:22 UTC 2015
 
 Modified Files:
  src/distrib/utils/embedded/conf: armv7.conf
 
 Log Message:
 add JETSONTK1 to armv7.img
 
 Please double-quote all variable expansions...

No, use the :Q modifier

Re: CVS commit: src/sys/arch/arm

[Matt Thomas]

 On May 19, 2015, at 2:20 AM, SUENAGA Hiroki hsuen...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: hsuenaga
 Date: Tue May 19 09:20:19 UTC 2015
 
 Modified Files:
   src/sys/arch/arm/arm: cpufunc_asm_pj4b.S
   src/sys/arch/arm/marvell: armadaxp.c mvsocreg.h
 
 Log Message:
 fix Marvell Coherency Barrier register address.
 configure coherency bus maintance broadcast using MPIDR. we need to configure
 this regardless of 'options MULTIPROCESSOR.'

Please move the MPIDR defines to arm/armreg.h and use __BIT or __BITS.

Re: CVS commit: src/common/lib/libc/arch/arm

[Matt Thomas]

 On May 17, 2015, at 1:57 PM, Justin Cormack jus...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: justin
 Date: Sun May 17 20:57:12 UTC 2015
 
 Modified Files:
   src/common/lib/libc/arch/arm/atomic: atomic_op_asm.h atomic_swap.S
   atomic_swap_16.S atomic_swap_64.S sync_bool_compare_and_swap_1.S
   sync_bool_compare_and_swap_2.S sync_bool_compare_and_swap_4.S
   sync_bool_compare_and_swap_8.S sync_fetch_and_add_8.S
   sync_fetch_and_and_8.S sync_fetch_and_nand_8.S
   sync_fetch_and_or_8.S sync_fetch_and_sub_8.S sync_fetch_and_xor_8.S
   src/common/lib/libc/arch/arm/string: ffs.S
 
 Log Message:
 Do not build arm toolchain symbols in the rump kernel
 
 These symbols will be provided at link time and will be
 duplicate symbols in rump kernel and libc if defined.
 
 Many have been fixed previously, but these were missed
 as did not have a test.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.6 -r1.7 src/common/lib/libc/arch/arm/atomic/atomic_op_asm.h
 cvs rdiff -u -r1.13 -r1.14 src/common/lib/libc/arch/arm/atomic/atomic_swap.S
 cvs rdiff -u -r1.3 -r1.4 src/common/lib/libc/arch/arm/atomic/atomic_swap_16.S 
 \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_add_8.S \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_and_8.S \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_or_8.S \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_sub_8.S \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_xor_8.S
 cvs rdiff -u -r1.9 -r1.10 \
   src/common/lib/libc/arch/arm/atomic/atomic_swap_64.S
 cvs rdiff -u -r1.1 -r1.2 \
   src/common/lib/libc/arch/arm/atomic/sync_bool_compare_and_swap_1.S \
   src/common/lib/libc/arch/arm/atomic/sync_bool_compare_and_swap_2.S \
   src/common/lib/libc/arch/arm/atomic/sync_bool_compare_and_swap_4.S
 cvs rdiff -u -r1.2 -r1.3 \
   src/common/lib/libc/arch/arm/atomic/sync_bool_compare_and_swap_8.S \
   src/common/lib/libc/arch/arm/atomic/sync_fetch_and_nand_8.S
 cvs rdiff -u -r1.7 -r1.8 src/common/lib/libc/arch/arm/string/ffs.S
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Most of these changes should have been in Makefile.inc, not in the sources 
themselves.

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

 On May 2, 2015, at 4:52 AM, Christos Zoulas chris...@zoulas.com wrote:
 
 On May 1,  1:46pm, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/mips/include
 
 | 
 |  On May 1, 2015, at 11:37 AM, Christos Zoulas chris...@netbsd.org wrote:
 |  
 |  Module Name:  src
 |  Committed By: christos
 |  Date: Fri May  1 18:37:40 UTC 2015
 |  
 |  Modified Files:
 |src/sys/arch/mips/include: locore.h
 |  
 |  Log Message:
 |  change #error to KASSERT
 |  
 |  
 |  To generate a diff of this commit:
 |  cvs rdiff -u -r1.95 -r1.96 src/sys/arch/mips/include/locore.h
 | 
 | This change is incorrect.  #error is the right thing for this case.
 
 Please read the comment in cpu.h:
 
 /* Assume all CPU architectures are valid for LKM's and standlone progs */
 
 You can't have it both ways... I.e. You'll need to make changes to cpu.h
 if you want to keep #error, or add more ifdefs around it.

Not all ABIs run on all CPU architectures.  N32/N64 are 64-bit only
so you can exclude all MIPS32 and MIPS1/MIPS2 cpus.

The ABI for the kernel must be the same as the ABI for modules.

This is not a CPU issue as much as an ABI issue.  And that’s invariant
so #error is correct.

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

 On May 1, 2015, at 11:37 AM, Christos Zoulas chris...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: christos
 Date: Fri May  1 18:37:40 UTC 2015
 
 Modified Files:
   src/sys/arch/mips/include: locore.h
 
 Log Message:
 change #error to KASSERT
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.95 -r1.96 src/sys/arch/mips/include/locore.h

This change is incorrect.  #error is the right thing for this case.

Re: CVS commit: src/sys/arch/arm

[Matt Thomas]

 On Apr 7, 2015, at 1:27 AM, Ryota Ozaki ozak...@netbsd.org wrote:
 
 On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson sk...@netbsd.org wrote:
 On 04/07/15 04:19, Ryota Ozaki wrote:
 
 Module Name:src
 Committed By:   ozaki-r
 Date:   Tue Apr  7 03:19:25 UTC 2015
 
 Modified Files:
   src/sys/arch/arm/ep93xx: ep93xx_intr.c
   src/sys/arch/arm/ixp12x0: ixp12x0_intr.c
 
 Log Message:
 Add missing #include arm/cpu.h
 
 sys/lwp.h is preferred, I think
 
 I see. It works for me too. I'll change so.
 
 Just curious, why is sys/lwp.h better?
 Because it is MI while arm/cpu.h is MD?

arm/cpu.h has a dependency on sys/lwp.h

Re: CVS commit: src/sys/net

[Matt Thomas]

 On Nov 26, 2014, at 11:26 PM, Masao Uebayashi uebay...@gmail.com wrote:
 
 On Thu, Nov 27, 2014 at 4:20 PM, Matt Thomas m...@3am-software.com wrote:
 Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(),
 as struct device did.
 
 Doesn't work since struct ifnet is embedded in ethercom/fddicom
 
 Right.  I mean, I want to make them alloc'ed to improve modlarity in
 the long run.

Eww.  Yet more indirection.  Most ifnet's live in a ethercom which
lives in a softc allocated by autoconf.  

Re: CVS commit: src/sys/net

[Matt Thomas]

 On Nov 26, 2014, at 1:38 AM, Ryota Ozaki ozak...@netbsd.org wrote:
 
 Module Name:  src
 Committed By: ozaki-r
 Date: Wed Nov 26 09:38:42 UTC 2014
 
 Modified Files:
   src/sys/net: if.c if.h
 
 Log Message:
 Change if_slowtimo_ch to a pointer
 
 One benefit to do so is to reduce memory used for struct callout;
 we can avoid to allocate struct callout for interfaces that don't
 use callout.
 
 Requested by uebayasi@.

This requires a kernel version bump.

Re: CVS commit: src/sys/net

[Matt Thomas]

 On Nov 26, 2014, at 5:55 PM, Masao Uebayashi uebay...@gmail.com wrote:
 
 On Thu, Nov 27, 2014 at 10:51 AM, Masao Uebayashi uebay...@gmail.com wrote:
 Maybe adding a few spare members, like 5 pointers, to reduce # of bumps ... ?
 
 Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(),
 as struct device did.

Doesn't work since struct ifnet is embedded in ethercom/fddicom

Re: CVS commit: src/sys/arch

[Matt Thomas]

 On Nov 11, 2014, at 6:19 PM, Michael macal...@netbsd.org wrote:
 
 Hello,
 
 On Tue, 11 Nov 2014 23:14:18 +0100
 Martin Husemann mar...@duskware.de wrote:
 
 On Tue, Nov 11, 2014 at 02:10:08PM -0800, John Nemeth wrote:
 } The latest import fixed m68k (but tsutsui-san asked for a bit more 
 testing,
 } which I didn't manage to get around too yet).
 } 
 } If you switch, more people will test :-)
 
Or, tsutsui-san will back it out.  :-
 
 The request for more testing before switching was not unreasonable, and
 I bet the amount of people testing -current on m68k is pretty limited anyway.
 
 However, I'm updating my mac68k right now and will do a full atf test run
 ASAP.
 
 On macppc atf-run itself segfaults in __tls_get_addr()
 Makes me wonder if the problem is the same as chs just fixed in the kernel.

joerg did change mcontext.h for clang.  

Re: CVS commit: src/sys/dev

[Matt Thomas]

 On Nov 5, 2014, at 6:09 PM, Masao Uebayashi uebay...@gmail.com wrote:
 
 On Thu, Nov 6, 2014 at 4:03 AM, Taylor R Campbell
 campbell+netbsd-source-change...@mumble.net wrote:
 Why use a string-keyed table with run-time lookups instead of a C
 object with a C declaration?
 
 /* ioconf.h */
 extern struct cfiattrdata xxxbus;
 
 /* xxx.c */
config_found(self, xxxbus);
 
 I tend to prefer indirect lookup to direct reference almost everywhere
 in config(9).  But in this case reference would be fine.

Move this to tech-kern.

Re: CVS commit: src/usr.bin/config

[Matt Thomas]

 On Oct 29, 2014, at 7:30 PM, Christos Zoulas chris...@zoulas.com wrote:
 
 On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
 -- Subject: Re: CVS commit: src/usr.bin/config
 
 | Could you show me an example failure senario?  What do you propose instead?
 
 I don't have anything *better* to propose. I think mach-o constructors
 are different.
 
 | I heard that rump fixed linkset problem using .ctors/.dtors.
 | 
 | But .ctors/.dtors in kernel is just analogy of the userland one; it
 | may use the same section names but the internal behavior can be
 | defferent.
 
 Sure, I am not sure that all the object formats support them though.

arm doesn’t use .ctors/.dtors 

it has init/fini array instead.

and where would they be executed?

Re: CVS commit: src/sys/arch/arm/imx

[Matt Thomas]

On Oct 7, 2014, at 2:36 AM, Ryo Shimizu r...@netbsd.org wrote:

 Module Name:  src
 Committed By: ryo
 Date: Tue Oct  7 09:36:09 UTC 2014
 
 Modified Files:
   src/sys/arch/arm/imx: files.imx6 imx6_ccm.c imx6_ccmvar.h
 Added Files:
   src/sys/arch/arm/imx: imx6_i2c.c
 
 Log Message:
 add support imx6 I2C Controller

This should be using dev/i2c/motoi2c*

Re: CVS commit: src/sys/conf

[Matt Thomas]

On Sep 26, 2014, at 12:32 AM, David Holland dholland-sourcechan...@netbsd.org 
wrote:

 On Fri, Sep 19, 2014 at 09:05:23AM +, Matt Thomas wrote:
 Added Files:
  src/sys/conf: filesystems.config
 
 Log Message:
 include for configs which includes all file-systems and any dependent
 pseudo-devices
 
 Was this discussed anywhere?

No.  But follows in the of dev/usb/usbdevices.config

 I'm not saying it's a bad idea; I'm just not convinced this is how we
 want to do it.

I haven't changed any configs to use it.  Rather than cutting and pasting
the same list in every kernel, sometime that list is incomplete, I think
it's better to include a standard list and then no ... disable ones you
don't want.

Re: CVS commit: src/sys/external/bsd/drm/dist/shared-core

[Matt Thomas]

On Sep 6, 2014, at 12:28 PM, Cherry G. Mathew cherry.g.mat...@gmail.com wrote:

 Hi Matt,
 
 This doesn't fix drm2 i915 breakage. Could you revisit this please, since 
 it's in external/ ?
 
 Thanks,
 

If I revert, it still won't build.  So no.

i915 shouldn't be using enum pipe since it conflicts with struct pipe.

Re: CVS commit: src/sys/arch

[Matt Thomas]

 On Aug 29, 2014, at 4:46 AM, Reinoud Zandijk rein...@netbsd.org wrote:
 
 Mi Matthew,
 
 On Fri, Aug 29, 2014 at 09:53:31AM +1000, matthew green wrote:
 
 Reinoud Zandijk writes:
 Module Name:src
 Committed By:   reinoud
 Date:   Thu Aug 28 18:02:37 UTC 2014
 
 Modified Files:
 src/sys/arch/arm/samsung: exynos_io.c exynos_soc.c exynos_var.h
 src/sys/arch/evbarm/odroid: odroid_machdep.c
 
 Log Message:
 Implement CPU speed control for Exynos4 and Exynos5 CPUs using APLL 
 frequency
 adjustment.
 
 this change seems broken as it modifies cpu_counter specific
 information in cpu_data.
 
 It might be wrong, but all the evbarm architectures i've seen refect the cpu
 freq. in that variable. Not sure even if it needs to be updated on frequency
 changes. I'll dig into this though i'd love to see some more information!

Of course it need to be updated.  

Re: CVS commit: src/sys/arch

[Matt Thomas]

On Jul 24, 2014, at 5:23 PM, matthew green m...@eterna.com.au wrote:

 
 Taylor R Campbell writes:
 Module Name: src
 Committed By:riastradh
 Date:Thu Jul 24 13:42:29 UTC 2014
 
 Modified Files:
  src/sys/arch/amd64/include: vmparam.h
  src/sys/arch/i386/include: vmparam.h
  src/sys/arch/x86/x86: x86_machdep.c
 
 Log Message:
 Add a FIRST1G page freelist to x86, for old graphics devices.
 
 other devices that do this didn't have to change the
 platform code to do it.  see bce(4), which is limited
 to 1GB of ram on laptops that have 2GB.

That maybe true, but using a freelist makes the allocations
much cheaper. 

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

On Jul 23, 2014, at 1:46 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote:

 On Tue, Jul 22, 2014 at 10:40:02PM +0100, Alexander Nasonov wrote:
 Matt Thomas wrote:
 
 On Jul 22, 2014, at 2:27 PM, Alexander Nasonov al...@yandex.ru wrote:
 I allocate with the X flag and it seems to work:
 
 /* in sljitExecAllocator.c */
   return (void *)uvm_km_alloc(module_map, size,
   PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC);
 
 ok.  Then you need don't a hook for cache flushing
 
 pmap_protect(vm_map_pamp(module_map), va, size) will do that for you.
 At least for arm/mips/ppc/vax.  (e.g. changing a writeable exec page
 to read-only automatically causes it exec cleaned).
 
 sljit allocates 64K exec chucks which are managed by a special allocator.
 You need to run pmap_protect for each chunk. I think it's cheaper to
 flush icache.
 
 Wouldn't it be preferable to have *two* mappings for the code? One which
 is writeable and another which is executable?

won’t give you cleaning by the pmap since that’s done by pmap_protect.

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

On Jul 22, 2014, at 12:54 PM, Alexander Nasonov al...@netbsd.org wrote:

 Module Name:  src
 Committed By: alnsn
 Date: Tue Jul 22 19:54:55 UTC 2014
 
 Modified Files:
   src/sys/arch/mips/include: sljitarch.h
 
 Log Message:
 Define SLJIT_CACHE_FLUSH() for mips.

Actually, this isn't enough.  You need to allocate a page of mapped
memory as RWX and then when you are done use pmap_protect to change
it to RX followed by pmap_update() and the pmap will automagically
sync the page for you.

Indeed, you must make sure the page containing the code had
execute protect which the kmem_* routines won't give you.

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

On Jul 22, 2014, at 2:27 PM, Alexander Nasonov al...@yandex.ru wrote:

 Matt Thomas wrote:
 
 On Jul 22, 2014, at 12:54 PM, Alexander Nasonov al...@netbsd.org wrote:
 
 Module Name:src
 Committed By:   alnsn
 Date:   Tue Jul 22 19:54:55 UTC 2014
 
 Modified Files:
 src/sys/arch/mips/include: sljitarch.h
 
 Log Message:
 Define SLJIT_CACHE_FLUSH() for mips.
 
 Actually, this isn't enough.  You need to allocate a page of mapped
 memory as RWX and then when you are done use pmap_protect to change
 it to RX followed by pmap_update() and the pmap will automagically
 sync the page for you.
 
 I allocate with the X flag and it seems to work:
 
 /* in sljitExecAllocator.c */
return (void *)uvm_km_alloc(module_map, size,
PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC);

ok.  Then you need don't a hook for cache flushing

pmap_protect(vm_map_pamp(module_map), va, size) will do that for you.
At least for arm/mips/ppc/vax.  (e.g. changing a writeable exec page
to read-only automatically causes it exec cleaned).

Re: CVS commit: src/sys/arch/mips/include

[Matt Thomas]

On Jul 22, 2014, at 2:40 PM, Alexander Nasonov al...@yandex.ru wrote:

 Matt Thomas wrote:
 
 On Jul 22, 2014, at 2:27 PM, Alexander Nasonov al...@yandex.ru wrote:
 I allocate with the X flag and it seems to work:
 
 /* in sljitExecAllocator.c */
   return (void *)uvm_km_alloc(module_map, size,
   PAGE_SIZE, UVM_KMF_WIRED | UVM_KMF_ZERO | UVM_KMF_EXEC);
 
 ok.  Then you need don't a hook for cache flushing
 
 pmap_protect(vm_map_pamp(module_map), va, size) will do that for you.
 At least for arm/mips/ppc/vax.  (e.g. changing a writeable exec page
 to read-only automatically causes it exec cleaned).
 
 sljit allocates 64K exec chucks which are managed by a special allocator.
 You need to run pmap_protect for each chunk. I think it's cheaper to
 flush icache.

Maybe.  But I'd prefer executable code to be in read-only pages so that
malicious code can't be placed in them and executed.  I think trading
space for security is a valid tradeoff.

Re: CVS commit: src/sys/arch/arm/include

[Matt Thomas]

On Jul 22, 2014, at 1:16 PM, Alexander Nasonov al...@netbsd.org wrote:

 Module Name:  src
 Committed By: alnsn
 Date: Tue Jul 22 20:16:39 UTC 2014
 
 Modified Files:
   src/sys/arch/arm/include: sljitarch.h
 
 Log Message:
 Add parentheses around macro arguments.

Please use sljit_machdep.h to follow the standard
netbsd convention.

Re: CVS commit: src/sys/arch/arm/include

[Matt Thomas]

On Jul 22, 2014, at 3:45 PM, Alexander Nasonov al...@yandex.ru wrote:

 Matt Thomas wrote:
 
 On Jul 22, 2014, at 1:16 PM, Alexander Nasonov al...@netbsd.org wrote:
 
 Module Name:src
 Committed By:   alnsn
 Date:   Tue Jul 22 20:16:39 UTC 2014
 
 Modified Files:
 src/sys/arch/arm/include: sljitarch.h
 
 Log Message:
 Add parentheses around macro arguments.
 
 Please use sljit_machdep.h to follow the standard
 netbsd convention.
 
 How strict are we about following this rule? These files were around for
 a while and there are 29 of them. It's quite a bit of mechanical work
 to rename them and obsolete old files.

I don't think we want to start a new precedent.  I admit it's a pain
but it's the right thing to do.

Re: CVS commit: src/external/lgpl3/gmp/dist

[Matt Thomas]

On Jun 23, 2014, at 5:48 AM, KIYOHARA Takashi kiyoh...@netbsd.org wrote:

 Module Name:  src
 Committed By: kiyohara
 Date: Mon Jun 23 12:48:43 UTC 2014
 
 Modified Files:
   src/external/lgpl3/gmp/dist: configure
 
 Log Message:
 Support earm*-*-*.

why?  we don't use that.

Re: CVS commit: src/lib/libedit/TEST

[Matt Thomas]

On Jun 18, 2014, at 1:12 PM, Christos Zoulas chris...@netbsd.org wrote:

 cast gotsig because it is long on some systems.

Why cast to int instead of long?

Re: CVS commit: src/sys/arch/sgimips/conf

[Matt Thomas]

On Jun 1, 2014, at 1:29 PM, matthew green m...@eterna.com.au wrote:

 
 hmmm, isn't n32 kernel a relatively uncommon way of setting up the
 new mips code?  i'm not sure matt ever tested that properly, but
 it seems to me it should be capable of running o32, n32 and n64
 applications, but matt should have a look at this..
 
 (i'm pretty sure the designed method is to run n64 kernels and
 to have n32 userland default, with both o32 and n64 userland
 compat available.)

N32 or N64 kernels are fine.  I've used both.

Re: CVS commit: src/sys/arch/sgimips/conf

[Matt Thomas]

On Jun 1, 2014, at 9:45 PM, matthew green m...@eterna.com.au wrote:

 
 Matt Thomas writes:
 
 On Jun 1, 2014, at 1:29 PM, matthew green m...@eterna.com.au wrote:
 
 
 hmmm, isn't n32 kernel a relatively uncommon way of setting up the
 new mips code?  i'm not sure matt ever tested that properly, but
 it seems to me it should be capable of running o32, n32 and n64
 applications, but matt should have a look at this..
 
 (i'm pretty sure the designed method is to run n64 kernels and
 to have n32 userland default, with both o32 and n64 userland
 compat available.)
 
 N32 or N64 kernels are fine.  I've used both.
 
 on sgimips?  (or cobalt? :)

evbmips

 what userland in both cases?

n32 and o32.

Re: CVS commit: src/sys/arch/mips/mips

[Matt Thomas]

On Apr 30, 2014, at 9:14 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 skrll@ wrote:
 
 I'm still seeing issues with my cobalt, but I'll keep hunting.
 
 Probably all mips port MD bus_dma.c
 (in arc, cobalt, emips, ews4800mips, hpcmips, mipsco, pmax, sgimips)
 need the similar fix as mips/bus_dma.c rev 1.28.
 (only algor, evbmips and sbmips use mips/bus_dma.c)

they should also switch to the common mips bus space/dma files.

Re: CVS commit: src/share/mk

[Matt Thomas]

On Apr 9, 2014, at 9:29 AM, Christos Zoulas chris...@netbsd.org wrote:

 Module Name:  src
 Committed By: christos
 Date: Wed Apr  9 16:29:08 UTC 2014
 
 Modified Files:
   src/share/mk: bsd.lib.mk
 
 Log Message:
 change -x to OBJCOPYLIBFLAGS like everywhere else.

Does that really fix it?  since .target is not a .po that should allow -x as 
well.

${${.TARGET:M*.po} != :?-X:-x}

Re: CVS commit: src/external/cddl/osnet/lib/libdtrace

[Matt Thomas]

On Mar 15, 2014, at 10:11 PM, Ryota Ozaki ozak...@netbsd.org wrote:

 Module Name:  src
 Committed By: ozaki-r
 Date: Sun Mar 16 05:11:19 UTC 2014
 
 Modified Files:
   src/external/cddl/osnet/lib/libdtrace: Makefile
 
 Log Message:
 Look up arm directory on MACHINE_ARCH=*arm*

Use MACHINE_CPU instead.

Re: CVS commit: src/sys/uvm

[Matt Thomas]

On Feb 27, 2014, at 11:07 PM, Alan Barrett a...@cequrux.com wrote:

 On Wed, 26 Feb 2014, Matt Thomas wrote:
 Modified Files:
  src/sys/uvm: uvm_meter.c uvm_param.h
 
 Log Message:
 Add vm.min_address and vm.max_address which return VM_MIN_ADDRESS and
 VM_MAXUSER_ADDRESS.
 
 Do these need to use the old style #define constants
 instead of the new style (since 2005) CTL_CREATE idiom?

Don't need to but I think it's lower overhead if they use
old style definitions.

Re: CVS commit: src/share/mk

[Matt Thomas]

On Feb 27, 2014, at 12:43 PM, matthew green m...@netbsd.org wrote:

 remove the GCC 4 EXTERNAL_GCC_SUBDIR, and switch GCC 4.8 to use gcc.old.

huh?

Re: CVS commit: src/share/mk

[Matt Thomas]

On Jan 23, 2014, at 8:53 PM, Masao Uebayashi uebay...@gmail.com wrote:

 How about kernel modules?

even kernel modules

Re: CVS commit: src/sys/external/bsd/compiler_rt/dist/lib

[Matt Thomas]

On Feb 19, 2014, at 2:40 PM, Christos Zoulas chris...@astron.com wrote:

 In article 20140219205453.gb22...@britannica.bec.de,
 Joerg Sonnenberger  jo...@britannica.bec.de wrote:
 
 I have no problem with going over the code in the upstream repository,
 but I have a problem with adding pointless local changes. They just
 increase the cost of maintainance for absolute no good reason.
 
 There is a semantic difference here between the two, aside from __FUNCTION__
 not being in any standard. Do you think that the change is controvercial?

I've held off on committing local changes and worked with Joerg to feed
things upstream first.  It's been fairly painless.

Re: CVS commit: src/sys/arch

[Matt Thomas]

On Feb 5, 2014, at 3:06 PM, David Laight da...@l8s.co.uk wrote:

 On Wed, Feb 05, 2014 at 11:09:05PM +0100, Joerg Sonnenberger wrote:
 On Wed, Feb 05, 2014 at 06:52:22PM +, David Laight wrote:
 Module Name:src
 Committed By:   dsl
 Date:   Wed Feb  5 18:52:22 UTC 2014
 
 Modified Files:
 src/sys/arch/amd64/conf: Makefile.amd64
 src/sys/arch/i386/conf: Makefile.i386
 
 Log Message:
 Change the compiler options to explicitly specify:
  -mno-mmx -mno-sse -mno-avx -mno-80387 -mno-fp-ret-in-387
 Since no-sse implies no-sse2 that should ensure that the compiler really
  doesn't emit any instructions that might trap trying to use the FPU.
 On amd64 at least some of those are needed to stop the compiler
  saving the registers to stack on every varargs function.
 It might be that -mno-sse did that before.
 
 This breaks clang. Please do not depend on one SSE option disabling
 another.
 
 Without those flags I believe gcc might generate x87 instructions.
 Quite possibly even for amd64.
 See a very recent linux fix.
 Try searching for: Disable generation of traditional x87 instructions

I think Joerg is saying put in -mno-sse2 since that is not disabled
by -mno-sse when using clang.

Re: CVS commit: src/sys/arch

[Matt Thomas]

On Feb 5, 2014, at 3:43 PM, David Laight da...@l8s.co.uk wrote:

 On Wed, Feb 05, 2014 at 03:09:59PM -0800, Matt Thomas wrote:
 
 
 This breaks clang. Please do not depend on one SSE option disabling
 another.
 
 Without those flags I believe gcc might generate x87 instructions.
 Quite possibly even for amd64.
 See a very recent linux fix.
 Try searching for: Disable generation of traditional x87 instructions
 
 I think Joerg is saying put in -mno-sse2 since that is not disabled
 by -mno-sse when using clang.
 
 with the gcc I'm looking at (if I'm reading to code properly):
 no-sse = no-sse2 = no-sse3 = no-ssse3  no-sse4a = no-sse4_1
 = no-sse4_2 = no-avx = no-fma = no-fma4

But clang is not gcc. :)

 You either need all of them, and the one that the next sub-version
 of the cpu/compiler add, or you assume that the first ones imply the
 latter - at least to some degree.

From llvm/dist/llvm/lib/Target/X86/X86.td:

// All x86-64 hardware has SSE2, but we don't mark SSE2 as an implied
// feature, because SSE2 can be disabled (e.g. for compiling OS kernels)
// without disabling 64-bit mode.

Re: CVS commit: src/distrib/common

[Matt Thomas]

On Feb 1, 2014, at 2:16 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 matt@ wrote:
 
 Module Name: src
 Committed By:matt
 Date:Sat Feb  1 21:05:54 UTC 2014
 
 Modified Files:
  src/distrib/common: Makefile.crunch
 
 Log Message:
 Pass DBG to crunchgen so it can get into the created mk file.
 
 I think it should be set by each Makefile via CRUNCHGEN_FLAGS
 (several mips ports already have it), not in the common Makefile.

Most ramdisk Makefiles have a DBG=value which is ignored.
CRUNCHGEN_FLAGS is unobvious.

Re: CVS commit: src/sys/arch/arm/include

[Matt Thomas]

On Jan 29, 2014, at 12:25 PM, Alan Barrett a...@cequrux.com wrote:

 On Wed, 29 Jan 2014, Matt Thomas wrote:
 Modified Files:
  src/sys/arch/arm/include: int_fmtio.h int_mwgwtypes.h
 
 Log Message:
 Make {,u}int{8,16,32} be of type int.
 
 I think you mean:
 
 Make {,u}int_fast{8,16,32} be of type int.

i do

Re: CVS commit: src/share/mk

[Matt Thomas]

On Jan 24, 2014, at 1:16 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 Do you have any suggestion without boring work to rename all
 #include machine/foo.h lines and expand the machine path
 in MI files to ${MACHINE}/include?

I wish that cc/clang supported -isystem:NAME PATH and iquote:NAME PATH
which would look starting at PATH for includes that start with {,}NAME

If we had that, we wouldn't need the damn links at all. :)

-isystem:arm ${NETBSDSRCTOP}/sys/arch/arm/include

Re: CVS commit: src/distrib/vax/ramdisk

[Matt Thomas]

On Jan 24, 2014, at 4:19 AM, Martin Husemann mar...@netbsd.org wrote:

 Module Name:  src
 Committed By: martin
 Date: Fri Jan 24 12:19:10 UTC 2014
 
 Modified Files:
   src/distrib/vax/ramdisk: Makefile
 
 Log Message:
 Slightly bump ramdisk size, so the content fits even when compiled with
 gcc 4.8 (usually binaries are smaller or same size, this increase is
 strange)

Alas, as gcc improves support for riscish architectures, these enhancements
make CISCish code much worse.

I tried an experiment and limited the plus:QI and plus:HI patterns to
const_int and register and the code produced improved considerably.

I'm reworking vax.md to limit patterns will help.

Re: CVS commit: src/sys/arch/arm

[Matt Thomas]

On Jan 11, 2014, at 9:32 AM, Matt Thomas m...@netbsd.org wrote:

 Module Name:  src
 Committed By: matt
 Date: Sat Jan 11 17:32:20 UTC 2014
 
 Modified Files:
   src/sys/arch/arm/arm32: arm32_machdep.c fault.c
   src/sys/arch/arm/include: locore.h
 
 Log Message:
 Add hw.printfataltraps sysctl.  Always print fatal traps for init.  For all
 other processes, only do so if cpu_printfataltraps is true.

actaully it's machdep.printfataltraps.

Re: CVS commit: src/sys/dev/pci

[Matt Thomas]

On Jan 9, 2014, at 9:28 AM, SAITOH Masanobu msai...@netbsd.org wrote:

 Module Name:  src
 Committed By: msaitoh
 Date: Thu Jan  9 17:28:05 UTC 2014
 
 Modified Files:
   src/sys/dev/pci: pcidevs
 
 Log Message:
 Remove 88SE9128(0x913a) entry. At least one of 88SE9128 chip's
 product ID is 0x9123. I have this one. Add new 88SE912X entry
 with 0x9123. OK'ed by jakllsch.

sys/dev/pci/ahcisata_pci.c:170:25: error:
'PCI_PRODUCT_MARVELL2_88SE9128' undeclared here (not in a function)

Re: CVS commit: src/lib/libc/compiler_rt

[Matt Thomas]

On Dec 2, 2013, at 6:28 PM, Joerg Sonnenberger jo...@netbsd.org wrote:

 Module Name:  src
 Committed By: joerg
 Date: Tue Dec  3 02:28:51 UTC 2013
 
 Modified Files:
   src/lib/libc/compiler_rt: Makefile.inc
 
 Log Message:
 Add ARM (EABI) specific sources. Split off code that requires C11,
 unwind support in libc or overlaps with soft-float in preparation for
 using compiler-rt in the non-clang case.

How will interact with libkern?

Re: CVS commit: src/sys/arch/i386/conf

[Matt Thomas]

On Oct 23, 2013, at 11:42 AM, Jukka Ruohonen jruoho...@iki.fi wrote:

 On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote:
 On Wed, 23 Oct 2013, Matt Thomas wrote:
 
 Module Name:src
 Committed By:   matt
 Date:   Wed Oct 23 17:26:08 UTC 2013
 
 Modified Files:
 src/sys/arch/i386/conf: GENERIC XEN3_DOM0
 
 Log Message:
 Add xhci device
 
 When do we get a xhci(4) man page?   :)
 
 Also: ALL is missing from the list.

That's because ALL already has xhci in it.

Re: CVS commit: src/external/gpl3/binutils/usr.bin/ld

[Matt Thomas]

On Oct 1, 2013, at 9:07 AM, Nick Hudson sk...@netbsd.org wrote:

 Module Name:  src
 Committed By: skrll
 Date: Tue Oct  1 16:07:35 UTC 2013
 
 Modified Files:
   src/external/gpl3/binutils/usr.bin/ld: Makefile
 
 Log Message:
 Use G_enable_initfini_array and default to no while mknative is rerun.

In the meantime, shouldn't we enable

CPPFLAGS+=  -DHAVE_INITFINI_ARRAY

in libexec/ld.elf_so/x86_64/Makefile.inc

Re: CVS commit: src

[Matt Thomas]

On Jul 19, 2013, at 12:19 AM, Jukka Ruohonen jruoho...@iki.fi wrote:

 On Wed, Jul 17, 2013 at 10:36:26PM +, Matt Thomas wrote:
 Log Message:
 Some constification.
 Add kcpuset_clone, kcpuset_insersection, kcpuset_remove,
 kcpuset_ffs, kcpuset_ffs_intersecting,
 kcpuset_atomicly_merge, kcpuset_atomicly_intersect, kcpuset_atomicly_remove
 
 A small nit: kcpuset_atomic_set() vs. kcpuset_atomicly_*() makes the API
 look a little inconsistent...  I don't know which is right in terms of
 grammar, but the atomic_*()-versions appear to be the de facto standard.

There is a reason for the difference.

the atomic_{set,cler} are actually atomic.

the atomicly use atomic operation but since they work word-by-word
they aren't truly atomic.

Re: CVS commit: src/lib/csu/common

[Matt Thomas]

On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:

 
 Module Name: src
 Committed By:matt
 Date:Thu Jun 27 03:37:21 UTC 2013
 
 Modified Files:
  src/lib/csu/common: Makefile.inc
 
 Log Message:
 Add -fPIC to compile of crtbeginS.o
 
 what is this for?  crtbeginS.o is for static binaries isn't it?

crtbegin.o is for static
crtbeginS.o is for shared

Re: CVS commit: src/lib/csu/common

[Matt Thomas]

On Jun 27, 2013, at 8:33 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote:

 On Thu, Jun 27, 2013 at 08:03:06AM -0700, Matt Thomas wrote:
 
 On Jun 27, 2013, at 7:28 AM, matthew green m...@eterna.com.au wrote:
 
 
 Module Name:   src
 Committed By:  matt
 Date:  Thu Jun 27 03:37:21 UTC 2013
 
 Modified Files:
src/lib/csu/common: Makefile.inc
 
 Log Message:
 Add -fPIC to compile of crtbeginS.o
 
 what is this for?  crtbeginS.o is for static binaries isn't it?
 
 crtbegin.o is for static
 crtbeginS.o is for shared
 
 Actually, it is crtbegin.o for the main binary, crtbeginS.o for shared
 objects and crtbeginT.o for static binaries. Making crtbegin.o PIC is
 useful for PIE.


We don't build crtbeginT.o any more.

Re: CVS commit: src/sys

[Matt Thomas]

On Jun 5, 2013, at 7:24 AM, Greg Troxel g...@ir.bbn.com wrote:

 
 Jukka Ruohonen jruoho...@iki.fi writes:
 
 Ah, maybe IPv6-only hosts would be the rationale then. But as you noted, it
 is not difficult to find cases like
 
  #ifdef INET
...
  #ifdef INET6
 
 That's a bug; in theory one should be able to have INET6 without INET.
 I did try it once several years ago, and had some trouble that I didn't
 solve.

Not always.  Sometimes you need to check for an AF_INET6 socket in an
IPv4 path since you might be using mapped IPv4 addresses.

Re: CVS commit: src/tests/lib/libm

[Matt Thomas]

On May 24, 2013, at 6:44 AM, Martin Husemann mar...@duskware.de wrote:

 On Fri, May 24, 2013 at 09:08:18AM -0400, Christos Zoulas wrote:
 On May 24,  8:01am, mar...@homeworld.netbsd.org (Martin Husemann) wrote:
 -- Subject: Re: CVS commit: src/tests/lib/libm
 
 | This is wrong - unlike the other tests that use IEEE FP specific things,
 | the value tests should work on vax. I'll have a look and fix it properly.
 
 They could once you add scalbn to the vax libm. For now they don't link.
 
 Yes, exactly - your commit papered over a bug in the libm makefile
 (it is a real mess), starting with a typo and a value later overwriten
 by another assignment.
 
 Matt, any chance to get POLYD functional, so this could all be cleaned up?

vax asm.h has a polyd macro 

Re: CVS commit: src

[Matt Thomas]

On May 1, 2013, at 9:57 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 matt@ wrote:
 
 Module Name: src
 Committed By:matt
 Date:Thu May  2 03:56:43 UTC 2013
 :
 Log Message:
 This change arm, armeb, earm, earmeb, earmhf, earmhfeb so all builds that
 share a MACHINE_ARCH for userland so that except for etc, will produce
 identical sets.
 
 usr/include/machine now points to usr/include/arm
 
 How does MD disklabel.h work?
 
 At least hpcarm and zaurus don't use arm/disklabel.h.

Haven't fixed disklabel yet.  I'm adding a -m machine option to it.
which will select various things 

Re: CVS commit: src/sys/kern

[Matt Thomas]

On Apr 21, 2013, at 2:15 AM, David Laight da...@l8s.co.uk wrote:

 On Sat, Apr 20, 2013 at 02:17:17PM -0700, Matt Thomas wrote:
 
 On Apr 20, 2013, at 11:04 AM, Christos Zoulas chris...@netbsd.org wrote:
 
 Module Name:src
 Committed By:   christos
 Date:   Sat Apr 20 18:04:41 UTC 2013
 
 Modified Files:
 src/sys/kern: kern_exec.c
 
 Log Message:
 don't attempt to load elf64 on 32 bit machines
 
 if the load address doesn't fit in 4GB.
 
 I've run elf64(n64) on mips n32 kernel with no problems.
 
 Isn't an n32 kernel a 64bit one that uses 32bit pointers?
 A little unusual.
 
 Doesn't that require a COMPAT_64 layer in the kernel?
 Since user pointers will be 64bit and kernel ones only 32.

I cheated and used objcopy to convert a N32 binary to N64.

Re: CVS commit: src/sys/kern

[Matt Thomas]

On Apr 20, 2013, at 11:04 AM, Christos Zoulas chris...@netbsd.org wrote:

 Module Name:  src
 Committed By: christos
 Date: Sat Apr 20 18:04:41 UTC 2013
 
 Modified Files:
   src/sys/kern: kern_exec.c
 
 Log Message:
 don't attempt to load elf64 on 32 bit machines

if the load address doesn't fit in 4GB.

I've run elf64(n64) on mips n32 kernel with no problems.

Re: CVS commit: src/sys/sys

[Matt Thomas]

On Feb 24, 2013, at 12:37 AM, Iain Hibbert plu...@ogmig.net wrote:

 On Sun, 24 Feb 2013, Matt Thomas wrote:
 
 Module Name: src
 Committed By:matt
 Date:Sun Feb 24 06:20:24 UTC 2013
 
 Modified Files:
  src/sys/sys: tty.h
 
 Log Message:
 Add a t_softc member to struct tty in which a driver can store a pointer
 to its softc.  (analogous to if_softc in struct ifnet).
 
 Currently, all the tty drivers use a macro to extract an index to the
 devices private cfdriver array from the dev_t that is formed from the
 major/minor numbers and provided by the framework (and incidentally,
 already stored in the tty structure as t_dev)
 
 So what is your intention with this change? Are you changing the design
 and if so, has that been discussed on a public list?
 
 Having written tty drivers in the past, I do think this could do with a
 redesign, but I also feel that all uses should remain consistent..

It's not a radical change.  You can still use device_lookup_private on
tp-t_dev but now there is a cheaper method.  But store the sc pointer
in tp-t_softc after tty_alloc and then use that to retrieve it.

It's simply a little more efficient.  As I indicated, if_softc already
provides this functionality for struct ifnet.

Re: CVS commit: src/common/lib/libc/arch/arm/string

[Matt Thomas]

On Jan 15, 2013, at 12:10 AM, David Laight wrote:

 On Tue, Jan 15, 2013 at 02:03:31AM +, Matt Thomas wrote:
 Module Name: src
 Committed By:matt
 Date:Tue Jan 15 02:03:31 UTC 2013
 
 Added Files:
  src/common/lib/libc/arch/arm/string: strchr_naive.S strrchr_naive.S
 
 Log Message:
 Add simple/small versions of strchr/strrchr for ARM.
 
 If you use 'preindex with writeback' you can remove an instruction
 from the loop (in strchr at least).

I pretty much already do that.

 I'm also intrigued that these are the very simple/small versions
 whereas the memcpy() (I think) was one that did all the alignment
 and double-word copies!

As I said in its commit, the stupid version was very very slow.

Re: CVS commit: src/sys/arch/arm/arm

[Matt Thomas]

On Dec 27, 2012, at 7:48 PM, SAITOH Masanobu wrote:

 Module Name:  src
 Committed By: msaitoh
 Date: Fri Dec 28 03:48:00 UTC 2012
 
 Modified Files:
   src/sys/arch/arm/arm: cpufunc.c
 
 Log Message:
 Enable DCache Streaming Switch and Write Allocate.
 This change improve system performance significantly.

How does this affect L2 and DMA?

Re: CVS commit: src/sys/arch/arm

[Matt Thomas]

On Dec 9, 2012, at 6:02 PM, Christos Zoulas wrote:

 In article 20121210013731.5b86c17...@cvs.netbsd.org,
 Matt Thomas source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:matt
 Date:Mon Dec 10 01:37:31 UTC 2012
 
 Modified Files:
  src/sys/arch/arm/arm32: arm32_machdep.c cpuswitch.S fault.c genassym.cf
  vm_machdep.c
  src/sys/arch/arm/include: pcb.h
 
 Log Message:
 Rename pcb_sp/PCB_SP to pcb_ksp/PCB_KSP so that ipsec.c will compile.
 
 I already fixed that on head, in ipsec.c

I think sys/proc.h including machine/pcb.h is wrong.

Nothing in machine/pcb.h needs to be used by MI code.

Re: CVS commit: src/sys/arch/arm

[Matt Thomas]

On Dec 6, 2012, at 5:27 PM, Pierre Pronchery wrote:

 I'm afraid this has broken building the evbarm port, as it now fails with:
 
 src/external/gpl3/gdb/dist/gdb/armnbsd-nat.c: In function 
 'arm_supply_fparegset':
 src/external/gpl3/gdb/dist/gdb/armnbsd-nat.c:132:24: error: 'struct fpreg' 
 has no member named 'fpr'
 src/external/gpl3/gdb/dist/gdb/armnbsd-nat.c:135:29: error: 'struct fpreg' 
 has no member named 'fpr_fpsr'
 
 Should the changes to src/sys/arch/arm/include/reg.h be reflected within 
 gdb as well?

And they have been:

---BeginMessage---
Module Name:src
Committed By:   matt
Date:   Thu Dec  6 06:45:46 UTC 2012

Modified Files:
src/external/gpl3/gdb/dist/gdb: armnbsd-nat.c

Log Message:
Fetch VFP registers, not FPA.


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/external/gpl3/gdb/dist/gdb/armnbsd-nat.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

---End Message---

Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src

[Matt Thomas]

On Nov 4, 2012, at 2:26 AM, David Laight wrote:

 Personally I almost never mark variables 'const', the only I initialise
 in their declarations (at the top of a function) are probably almost
 always never chaned (well maybe execpt default error values).

Personally, I always mark variable as const if I don't expect its value to 
change since that documents that expectation.  This is especially true for 
pointers:

const struct foo_softc * const sc = ifp-if_softc;

Once nice side effect is that it catches errors like:

if (sc = NULL) {
}

Re: CVS commit: src

[Matt Thomas]

On Sep 11, 2012, at 11:19 PM, Emmanuel Dreyfus wrote:

 Matt Thomas m...@3am-software.com wrote:
 
 Only those ports which reserve a register in mcontext for the TCB
 pointer should define _UC_TLSBASE.  Otherwise _UC_TLSBASE has no
 meaning and thus should not be defined.
 
 Well, we have the choice between:
 - define it and keeep it unused
 - not define it add add #ifdef in libpthread and tests
 
 I chose the second alternative, an unused #ifdef for a simplier code

In this case, I would prefer an #ifdef

_UC_TLSBASE is an MD thing.  Defining it unconditionally bloats things.
For instance, if _UC_TLSBASE isn't defined, pthread_setcontext doesn't
need to do anything except call setcontext.  That's a win.

Re: CVS commit: src (_UC_TLSBASE)

[Matt Thomas]

On Sep 12, 2012, at 12:26 AM, Emmanuel Dreyfus wrote:

 On Tue, Sep 11, 2012 at 11:20:47PM -0700, Matt Thomas wrote:
 _UC_TLSBASE is an MD thing.
 
 iMO it is a MI interface with a MD implementation. It just says whether 
 TLS is part of struct mcontext or not. The MD code can handle that in 
 the kernel or in userland if that is possible.
 
 Defining it unconditionally bloats things.
 For instance, if _UC_TLSBASE isn't defined, pthread_setcontext doesn't
 need to do anything except call setcontext.  That's a win.
 
 But do we have any port that are in this situation? I understand
 they all change the TLS pointer with setcontext.

Actually, several don't.  arm doesn't, mips doesn't, vax doesn't,
m68k doesn't.  They may be others.

Re: CVS commit: src

[Matt Thomas]

On Sep 12, 2012, at 7:04 AM, Martin Husemann wrote:

 On Wed, Sep 12, 2012 at 01:00:52PM +, Christos Zoulas wrote:
 This is orthogonal. I believe that in the discussion we had in core
 we decided to not define _UC_TLSBASE unconditionally, and that ports
 should define it as needed.
 
 What does as needed mean here? Can you show an example of an arch not
 needing it?

arm and mips for instance.  They both have instructions that fetch the TCB 
pointer thus it's not kept in a specific register and not in the mcontext 
structure.  So they don't need _UC_TLSBASE since it will never be present in 
the ucontext_t.

Re: CVS commit: src/lib/libpthread

[Matt Thomas]

On Sep 12, 2012, at 9:45 AM, David Laight wrote:

 On Wed, Sep 12, 2012 at 02:55:48PM +, Matt Thomas wrote:
 Module Name: src
 Committed By:matt
 Date:Wed Sep 12 14:55:48 UTC 2012
 
 Modified Files:
  src/lib/libpthread: pthread_specific.c
 
 Log Message:
 Only copy the ucontext_t in pthread_setcontext if _UC_TLSBASE is set.
 Conditionalize the test on _UC_TLSBASE being defined.
 
 Why not just define it to be zero if it isn't needed ?

lint will complain. :(

Re: CVS commit: src

[Matt Thomas]

On Sep 11, 2012, at 7:00 PM, Emmanuel Dreyfus wrote:

 
 - add _UC_TLSBASE definition in header file for all ports
  (powerpc, sh3, sparc and sparc64 lack the implementation for now)

Only those ports which reserve a register in mcontext for the TCB
pointer should define _UC_TLSBASE.  Otherwise _UC_TLSBASE has no
meaning and thus should not be defined.

Re: CVS commit: src/sys

[Matt Thomas]

On Sep 4, 2012, at 12:55 PM, matthew green wrote:

 
 Module Name: src
 Committed By:matt
 Date:Sat Sep  1 00:24:44 UTC 2012
 
 Modified Files:
  src/sys/kern: kern_cpu.c
  src/sys/sys: cpu_data.h
 
 Log Message:
 Add a kcpuset_t which just includes ourself.
 Add a ci_cpuname for convenience
 
 there's already this i thought:
 
 sys/cpu_data.h:109:   charcpu_name[8];/* eg, 
 cpu4 */


I added

#define ci_cpuname ci_data.cpu_name

Re: CVS commit: src/sys/uvm

[Matt Thomas]

On Sep 3, 2012, at 3:33 PM, Mindaugas Rasiukevicius wrote:

 Matt Thomas m...@netbsd.org wrote:
 Module Name: src
 Committed By:matt
 Date:Mon Sep  3 19:53:43 UTC 2012
 
 Modified Files:
  src/sys/uvm: uvm_km.c uvm_map.c
 
 Log Message:
 Switch to a spin lock (uvm_kentry_lock) which, fortunately, was sitting
 there unused.
 
 - pmap_growkernel() may use adaptive locks, which cannot be acquired with
  the spin lock held; so the change breaks at least x86 and alpha.
 
 - Why in the caller?  I think it would be better do leave it for the pmaps,
  e.g. they may re-use the locks which already provide the necessary
  protection and which need to be taken anyway (like in x86 pmap).

uvm_maxkaddr need a lock for its updating

growkernel can be called uvm_km_mem_alloc which might be called
at interrupt level.

Re: CVS commit: src/sys

[Matt Thomas]

On Aug 3, 2012, at 10:35 PM, matthew green wrote:

 
 Module Name: src
 Committed By:matt
 Date:Fri Aug  3 18:08:02 UTC 2012
 
 Modified Files:
  src/sys/kern: makesyscalls.sh
  src/sys/sys: systm.h
 
 Log Message:
 If any argument of a syscall is a pointer, set SYCALL_ARG_PTR as a flag.
 
 hmmm... what are you gonna do with this? :-)

Not completely sure but I was thinking that when
before a netbsd emulation loads itself into execsw it
could go through the list of sysent structure, see how
many don't have PTRs and then allocate a new sysent
structure, copy its into it, and replace the calls of
its sysent that don't use pointers with the ones from
emul_netbsd's sysent array.

Now having a string_t or netbsd32_string_t instead
of using const char * would help things like open and
other pathname using syscalls and remove ARG_PTR from
them since the PTR they use isn't really important.

Re: CVS commit: src/sys/arch/evbmips/conf

[Matt Thomas]

On Jul 30, 2012, at 6:50 AM, KIYOHARA Takashi wrote:

 Module Name:  src
 Committed By: kiyohara
 Date: Mon Jul 30 13:50:06 UTC 2012
 
 Modified Files:
   src/sys/arch/evbmips/conf: ALCHEMY MALTA
 
 Log Message:
 Enable INET6.  Avoid build failed when enable ipf and disable INET6.

The problem is in IPF.  Please on't add hacks to fix it.

Re: CVS commit: src/sys/arch/evbmips/conf

[Matt Thomas]

On Jul 30, 2012, at 7:01 AM, Paul Goyette wrote:

 On Mon, 30 Jul 2012, KIYOHARA Takashi wrote:
 
 Module Name: src
 Committed By:kiyohara
 Date:Mon Jul 30 13:50:06 UTC 2012
 
 Modified Files:
  src/sys/arch/evbmips/conf: ALCHEMY MALTA
 
 Log Message:
 Enable INET6.  Avoid build failed when enable ipf and disable INET6.
 
 While this might be a stop-gap measure to get the build working, the right 
 action is to fix ipf so it builds without INET6.
 
 I have previously provided patches (attached again here) to fix this, and 
 those fixes have been sent upstream (to darrenr@).  As was already pointed 
 out, my patches should not be committed as-is due to my use of variable 
 initialization in the declaration...  :)

Uh, that's perfectly acceptable these days.

Re: CVS commit: src/sys/arch/sparc

[Matt Thomas]

On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:

 Module Name:  src
 Committed By: christos
 Date: Mon Jul 30 17:29:55 UTC 2012
 Modified Files:
   src/sys/arch/sparc/dev: kd.c
   src/sys/arch/sparc/sparc: machdep.c
 
 Log Message:
 move cn_tab initializationt to cpu_startup

cn_tab was used for early console access
cpu_startup is too late.

it needs to be done sometime before main is
called.

Re: CVS commit: src/sys/arch/sparc

[Matt Thomas]

On Jul 30, 2012, at 4:56 PM, Christos Zoulas wrote:

 On Jul 30, 11:37am, m...@3am-software.com (Matt Thomas) wrote:
 -- Subject: Re: CVS commit: src/sys/arch/sparc
 
 | 
 | On Jul 30, 2012, at 10:29 AM, Christos Zoulas wrote:
 | 
 |  Module Name:  src
 |  Committed By: christos
 |  Date: Mon Jul 30 17:29:55 UTC 2012
 |  Modified Files:
 |src/sys/arch/sparc/dev: kd.c
 |src/sys/arch/sparc/sparc: machdep.c
 |  
 |  Log Message:
 |  move cn_tab initializationt to cpu_startup
 | 
 | cn_tab was used for early console access
 | cpu_startup is too late.
 | 
 | it needs to be done sometime before main is
 | called.
 
 Should we make cn_tab md, and let the ports initialize it themselves?
 Any better ideas?

there should be a routine (its name varies) that gets called from the
assembly and in that you should set cn_tab.

Re: CVS commit: src/sys/dev/i2c

[Matt Thomas]

On Jul 28, 2012, at 10:52 PM, David Holland wrote:

 On Sat, Jul 28, 2012 at 10:22:46PM -0700, Matt Thomas wrote:
 Modified Files:
src/sys/dev/i2c: g760a.c
 
 Log Message:
 Use (void *) instead of (type **) which gcc complains about.
 
 At least one of these casts is discarding const and writing to the
 const object returned by sysctl_createv().
 
 const foo ** is not pointer to const, it's a pointer to a pointer to const.
 so void * does not discard const.
 
 It does; it's passing foo ** to a const foo ** argument and thereby
 discarding the const on the returned pointer.

No, it's passing void * which is ignoring, not discarding, the
'const foo *' and just using the last * which does not have a
const qualifier (if it did, it would const foo * const *).

Re: CVS commit: src/sys/dev/i2c

[Matt Thomas]

On Jul 28, 2012, at 9:29 PM, David Holland wrote:

 On Sat, Jul 28, 2012 at 11:03:47PM +, Matt Thomas wrote:
 Modified Files:
  src/sys/dev/i2c: g760a.c
 
 Log Message:
 Use (void *) instead of (type **) which gcc complains about.
 
 At least one of these casts is discarding const and writing to the
 const object returned by sysctl_createv().

const foo ** is not pointer to const, it's a pointer to a pointer to const.
so void * does not discard const.

 It looks as if the const annotations in kern_sysctlc are rubbish.
 Can anyone explain what the model is supposed to be?

Not a clue.

Re: CVS commit: src/sys/dev/sdmmc

[Matt Thomas]

On Jul 17, 2012, at 5:39 AM, Greg Troxel wrote:

 
  Modified Files:
  src/sys/dev/sdmmc: sdhc.c
 
  Log Message:
  Handle interrupt acknowledgement in the SDHC_FLAG_32BIT_ACCESS case in
  the same way as non-SDHC_FLAG_32BIT_ACCESS case.
 
  To generate a diff of this commit:
  cvs rdiff -u -r1.20 -r1.21 src/sys/dev/sdmmc/sdhc.c
 
 Two questions, one of which isn't about your change.
 
 It seems that the HREAD4 of SDHC_NINTR_STATUS is reading both that and
 SDHC_EINTR_STATUS, but it seems odd that those are addresses 0x30 and
 0x32, which don't seem 4-byte aligned.  So is it really ok to do an
 HREAD4 across boundaries like that?  It seems odd, but maybe it's about
 the bus and the chip is fine with it.

0x30 is aligned and that is the address that is read from a 32-bit acccess.

 In the non-32 case, it seems that the EINTR register is read and then
 written back exactly if the error bit is set in the NINTR register.  In
 the 32 case, it seems that the SDHC_ERROR_INTERRUPT bit is set in NINTR
 if any bits are set in EINTR, in addition to writing both.
 
 So while I see the point that the |= into status is effectively a dead
 store,
 
  it seems odd to have bits set in SDHC_EINTR_STATUS without
  SDHC_ERROR_INTERRUPT set in SDHC_NINTR_STATUS, and
  the two code paths seem different still

This is because the ESDHC doesn't set SDHC_ERROR_INTERRUPT in its
register since you've read SDHC_EINTR_STATUS and can see those bits
directly.  So, for the sdhc driver, it needs to be emulated.

 I'm curious if you've been seeing bits in EINTR without ERROR in NINTR,
 and what the symptoms are that provoked this fix - I have a system with
 an sdhc (on evbppc/P2020) that mostly works but has occasional write
 errors.

That is exactly what the ESDHC on the P2020 does.

Re: CVS commit: src/sys/dev/sdmmc

[Matt Thomas]

On Jul 17, 2012, at 7:08 AM, Greg Troxel wrote:

 So the 4-byte read causes the SDHC_ERROR_INTERRUPT not to get set because
 the same read reads EINTR_STATUS, or the chip that's in systems that need
 4-byte reads is different (ESDHC vs SDHC?)?

The chip does not implement SDHC_ERROR_INTERRUPT.  It's always 0.
It depends on the vendor.  Freescale decided to not set it.

Re: CVS commit: src/sys/common/pmap/tlb

[Matt Thomas]

On May 19, 2012, at 8:12 AM, Reinoud Zandijk wrote:

 Hi Matt,
 
 On Thu, May 17, 2012 at 04:20:19PM +, Matt Thomas wrote:
 Module Name: src
 Committed By:matt
 Date:Thu May 17 16:20:19 UTC 2012
 
 Modified Files:
  src/sys/common/pmap/tlb: pmap.c pmap.h
 
 Log Message:
 Add support for PMAP_GROWKERNEL
 
 Maybe an ignorant question from me, but where is this common/pmap/tlb used? Is
 it really a generic tlb driven pmap?

It's used by powerpc booke and i have changes so that it's used by mips as well.
I've been debating about using for powerpc ibm4xx.

And yes, it's really a generic soft tab driven pmap.

Re: CVS commit: [matt-nb5-mips64] src/sys/uvm

[Matt Thomas]

On Apr 11, 2012, at 7:34 PM, YAMAMOTO Takashi wrote:

 hi,
 
 Module Name: src
 Committed By:matt
 Date:Thu Apr 12 01:40:27 UTC 2012
 
 Modified Files:
  src/sys/uvm [matt-nb5-mips64]: uvm_extern.h uvm_fault.c uvm_km.c
  uvm_meter.c uvm_pdaemon.c uvm_pdaemon.h uvm_pdpolicy.h
  uvm_pdpolicy_clock.c uvm_stat.c
 
 Log Message:
 Separate object-less anon pages out of the active list if there is no swap
 device.  Make uvm_reclaimable and uvm.*estimatable understand colors and
 kmem allocations.
 
 i like the idea.
 
 - why the queue is inside the pdpolicy?
 
 - why don't you use PQ_SWAPBACKED?

that's only set when a swap slot has been allocated for it.  Since there's no 
swap, it'll never be set.

The problem I'm attacking is memory exhaustion.  Making sure that's pdaemon 
isn't consuming too many resources when it can't do anything.  the pdaemon 
would spin continuously with dirty reactivations and the above was an attempt 
to stop that.

It's still a work-in-progress.

Re: CVS commit: src/lib/libc/arch/mips/gen

[Matt Thomas]

On Mar 20, 2012, at 3:51 AM, Havard Eidnes wrote:

 Module Name:  src
 Committed By: he
 Date: Tue Mar 20 10:51:24 UTC 2012
 
 Modified Files:
   src/lib/libc/arch/mips/gen: fpgetmask.c fpgetsticky.c fpsetmask.c
   fpsetsticky.c
 
 Log Message:
 Cast to unsigned int before doing shift operations, to appease lint.

The change to mips/ieeefp.h fixed these errors.

Re: CVS commit: src/sys

[Matt Thomas]

On Mar 8, 2012, at 1:55 PM, Joerg Sonnenberger wrote:

 Module Name:  src
 Committed By: joerg
 Date: Thu Mar  8 21:55:45 UTC 2012
 
 Modified Files:
   src/sys/compat/netbsd32: syscalls.master
   src/sys/kern: syscalls.master
 
 Log Message:
 Add entry for _ksem_timedwait.

was netbsd32_netbsd.c updated for the new syscall?

Re: CVS commit: src/common/lib/libc/string

[Matt Thomas]

On Mar 2, 2012, at 11:15 AM, Alan Barrett wrote:

 On Fri, 02 Mar 2012, Jukka Ruohonen wrote:
 Log Message:
 Change CTASSERT to __CTASSERT (the spelling used in sys/cdefs.h),
 include sys/cdefs.h so that it will be defined,
 and move it to a better place.
 
 The previous CTASSERT would never have been used because
 of the ifdef.  If it had been used, it would have had
 unwanted effects from being just after the static inline
 that appears when BZERO is defined.
 
 Also move the __RCSID to a more conventional location.
 
 And what was the resolution with all this? (cf. useless changes?).
 
 Sorry, I don't understand what you mean.
 
 Please change the documentation too (and most of all, !).
 
 It seems taht CTASSERT is defined in libkern.h, so is available to
 kernel code.  I'll fix the documentation.

__CTASSERT is available everywhere

Re: CVS commit: src/lib/libc/arch

[Matt Thomas]

On Feb 27, 2012, at 12:35 PM, Joerg Sonnenberger wrote:

 On Mon, Feb 27, 2012 at 03:47:11PM +, Matt Thomas wrote:
 Module Name: src
 Committed By:matt
 Date:Mon Feb 27 15:47:11 UTC 2012
 
 Modified Files:
  src/lib/libc/arch/powerpc/sys: cerror.S
  src/lib/libc/arch/powerpc64/sys: cerror.S
 
 Log Message:
 PowerPC doesn't have CERROR since it never had a.out.
 Use _C_LABEL(__cerror) instead.
 
 Can we please be consistent on all platforms in this case?

No.  It is consistent.  platforms that formerly used a.out use CERROR.
platforms that didn't don't.

Re: CVS commit: src

[Matt Thomas]

On Feb 17, 2012, at 3:02 PM, Julio Merino wrote:

 On 2/17/12 5:58 PM, Matt Thomas wrote:
 
 On Feb 17, 2012, at 2:54 PM, Julio Merino wrote:
 
 On 2/17/12 5:45 PM, Matt Thomas wrote:
 
 On Feb 17, 2012, at 2:43 PM, Julio Merino wrote:
 So the modules are broken on purpose?
 
 Yes.
 
 Interesting.  If that's the case, shouldn't we break PAGE_SIZE for all 
 platforms and keep things consistent?
 
 For those with variable page sizes (like powerpc or mips), yes.
 
 I was asking about *all* platforms regardless of whether they have static or 
 variable page sizes.  Keeping this inconsistent seems like a very easy way of 
 writing non-portable code...

Again they should use PAGE_SIZE which can be constant or not.
No reason for a non-constant PAGE_SIZE on alpha or vax which has fixed sized 
pages.

 The modules that are broken (see the referenced PR for a list) fail due to 
 a missing uvmexp_pagesize symbol (*not* PAGE_SIZE itself), which I assumed 
 was there to prevent depending on the PAGE_SIZE compile-time constant.  I 
 understand this information not being statically-available because of 
 variable-page sizes in these platforms.
 
 properly should use uvmexp.pagesize instead.
 
 Aha, I see.  Does it make sense to keep the test after renaming PAGE_SIZE to 
 uvmexp.pagesize?  It's a public symbol after all and we really should have 
 tests for these, I think.
 
 Do we need to go over the broken modules one by one and replace PAGE_SIZE 
 with uvmexp.pagesize?  (I'm expecting this won't be as easy as it sounds due 
 to preprocessor conditionals et. al.)

They should still use PAGE_SIZE which should evaluate to uvmexp.pagesize

Re: CVS commit: src

[Matt Thomas]

On Feb 17, 2012, at 2:54 PM, Julio Merino wrote:

 On 2/17/12 5:45 PM, Matt Thomas wrote:
 
 On Feb 17, 2012, at 2:43 PM, Julio Merino wrote:
 
 On 2/17/12 5:43 PM, Matt Thomas wrote:
 
 On Feb 17, 2012, at 2:36 PM, Julio Merino wrote:
 
 Module Name:  src
 Committed By: jmmv
 Date: Fri Feb 17 22:36:50 UTC 2012
 
 Modified Files:
   src/distrib/sets/lists/tests: module.mi
   src/tests/modules: Makefile
 Added Files:
   src/tests/modules: t_abi_uvm.sh
   src/tests/modules/k_uvm: Makefile k_uvm.c
 
 Log Message:
 Add a test to ensure that PAGE_SIZE is available in kernel modules.
 This test reproduces the error condition in PR port-macppc/46041 and
 therefore it is an xfail in this particular platform.
 
 I explicitly made PAGE_SIZE unavailable for powerpc.  This was part
 of having one consistent view for OEA,BOOKE,IBM4XX all which use
 different page size.  So you can't rely on PAGE_SIZE.
 
 So the modules are broken on purpose?
 
 Yes.
 
 Interesting.  If that's the case, shouldn't we break PAGE_SIZE for all 
 platforms and keep things consistent?

For those with variable page sizes (like powerpc or mips), yes.

 The modules that are broken (see the referenced PR for a list) fail due to a 
 missing uvmexp_pagesize symbol (*not* PAGE_SIZE itself), which I assumed was 
 there to prevent depending on the PAGE_SIZE compile-time constant.  I 
 understand this information not being statically-available because of 
 variable-page sizes in these platforms.

properly should use uvmexp.pagesize instead.

Re: CVS commit: src/sys/dev

[Matt Thomas]

Looking some advice.

I have some changed to get sdhc working with the FreeScale ESDHC.
But they are somewhat invasive and are not quite working right.

Do you have to have a machine with one?

the diffs for sdhc.c are in www.netbsd.org/sdhc.txt

Are you planning on supporting ADMA?

Re: CVS commit: src/sys/arch

[Matt Thomas]

On Sep 20, 2011, at 3:00 PM, Jean-Yves Migeon wrote:

 On 20.09.2011 02:12, Jean-Yves Migeon wrote:
 Module Name: src
 Committed By:jym
 Date:Tue Sep 20 00:12:25 UTC 2011
 
 Modified Files:
 [snip]
 Log Message:
 Merge jym-xensuspend branch in -current. ok bouyer@.
 
 Goal: save/restore support in NetBSD domUs, for i386, i386 PAE and amd64.
 [snip]
 XXX PAE suspend does not work in amd64 currently, due to (yet again!)
 page validation issues with hypervisor. Will fix.
 
 Got it, pool cache invalidation is not working as expected during save. I 
 remember discussing this matter with Mindaugas a while back, and due to 
 pool_cache(9) limitations back then the code was commented out (see the #if 0 
 ... #endif part in pool_cache_invalidate).
 
 I had to implement a pool_cache_invalidate_local(), but this wasn't 
 technically appreciated by many as it made pool_cache abstraction leaky (and 
 they were right)
 
 I'll discuss this matter again, I think I have an alternative solution for 
 that one. I may hit a pmf(9) limitation though :/

Maybe add pmf hook for cpu device_t in mi_cpu_attach

Re: CVS commit: src/share/man/man4

[Matt Thomas]

On Aug 30, 2011, at 4:06 PM, Simon Burge wrote:

 Martin Husemann wrote:
 
 Just curious: are there analog TV feeds out there, anywhere, still?
 
 Some parts of Australia until the end of next year...

Quite a few according to 

http://en.wikipedia.org/wiki/List_of_digital_television_deployments_by_country

Re: CVS commit: src

[Matt Thomas]

Please do MKDEBUG=yes builds.

You missed adding:

./usr/libdata/debug/sbin/fsck_v7fs.debug
./usr/libdata/debug/sbin/mount_v7fs.debug
./usr/libdata/debug/sbin/newfs_v7fs.debug

On Jun 27, 2011, at 4:52 AM, UCHIYAMA Yasushi wrote:

 Module Name:  src
 Committed By: uch
 Date: Mon Jun 27 11:52:58 UTC 2011
 
 Modified Files:
   src/distrib/sets/lists/base: mi
   src/distrib/sets/lists/comp: mi
   src/distrib/sets/lists/man: mi
   src/sbin: Makefile
   src/sys/conf: files
   src/sys/fs: Makefile
   src/sys/sys: disklabel.h mount.h vnode.h
 Added Files:
   src/sbin/fsck_v7fs: Makefile datablock.c freeblock.c fsck_v7fs.8
   fsck_v7fs.c fsck_v7fs.h inode.c main.c pathname.c
   src/sbin/mount_v7fs: Makefile mount_v7fs.8 mount_v7fs.c mount_v7fs.h
   src/sbin/newfs_v7fs: Makefile main.c newfs_v7fs.8 newfs_v7fs.c
   newfs_v7fs.h
   src/sys/fs/v7fs: Makefile files.v7fs v7fs.h v7fs_args.h
   v7fs_datablock.c v7fs_datablock.h v7fs_dirent.c v7fs_dirent.h
   v7fs_endian.c v7fs_endian.h v7fs_extern.c v7fs_extern.h v7fs_file.c
   v7fs_file.h v7fs_file_util.c v7fs_impl.h v7fs_inode.c v7fs_inode.h
   v7fs_inode_util.c v7fs_io.c v7fs_io_kern.c v7fs_io_user.c
   v7fs_superblock.c v7fs_superblock.h v7fs_superblock_util.c
   v7fs_vfsops.c v7fs_vnops.c
 
 Log Message:
 7th Edition(V7) File System support. and NetBSD symbolic-link, socket, FIFO 
 extension. see newfs_v7fs(8).
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.939 -r1.940 src/distrib/sets/lists/base/mi
 cvs rdiff -u -r1.1632 -r1.1633 src/distrib/sets/lists/comp/mi
 cvs rdiff -u -r1.1321 -r1.1322 src/distrib/sets/lists/man/mi
 cvs rdiff -u -r1.119 -r1.120 src/sbin/Makefile
 cvs rdiff -u -r0 -r1.1 src/sbin/fsck_v7fs/Makefile \
src/sbin/fsck_v7fs/datablock.c src/sbin/fsck_v7fs/freeblock.c \
src/sbin/fsck_v7fs/fsck_v7fs.8 src/sbin/fsck_v7fs/fsck_v7fs.c \
src/sbin/fsck_v7fs/fsck_v7fs.h src/sbin/fsck_v7fs/inode.c \
src/sbin/fsck_v7fs/main.c src/sbin/fsck_v7fs/pathname.c
 cvs rdiff -u -r0 -r1.1 src/sbin/mount_v7fs/Makefile \
src/sbin/mount_v7fs/mount_v7fs.8 src/sbin/mount_v7fs/mount_v7fs.c \
src/sbin/mount_v7fs/mount_v7fs.h
 cvs rdiff -u -r0 -r1.1 src/sbin/newfs_v7fs/Makefile \
src/sbin/newfs_v7fs/main.c src/sbin/newfs_v7fs/newfs_v7fs.8 \
src/sbin/newfs_v7fs/newfs_v7fs.c src/sbin/newfs_v7fs/newfs_v7fs.h
 cvs rdiff -u -r1.1017 -r1.1018 src/sys/conf/files
 cvs rdiff -u -r1.19 -r1.20 src/sys/fs/Makefile
 cvs rdiff -u -r0 -r1.1 src/sys/fs/v7fs/Makefile src/sys/fs/v7fs/files.v7fs \
src/sys/fs/v7fs/v7fs.h src/sys/fs/v7fs/v7fs_args.h \
src/sys/fs/v7fs/v7fs_datablock.c src/sys/fs/v7fs/v7fs_datablock.h \
src/sys/fs/v7fs/v7fs_dirent.c src/sys/fs/v7fs/v7fs_dirent.h \
src/sys/fs/v7fs/v7fs_endian.c src/sys/fs/v7fs/v7fs_endian.h \
src/sys/fs/v7fs/v7fs_extern.c src/sys/fs/v7fs/v7fs_extern.h \
src/sys/fs/v7fs/v7fs_file.c src/sys/fs/v7fs/v7fs_file.h \
src/sys/fs/v7fs/v7fs_file_util.c src/sys/fs/v7fs/v7fs_impl.h \
src/sys/fs/v7fs/v7fs_inode.c src/sys/fs/v7fs/v7fs_inode.h \
src/sys/fs/v7fs/v7fs_inode_util.c src/sys/fs/v7fs/v7fs_io.c \
src/sys/fs/v7fs/v7fs_io_kern.c src/sys/fs/v7fs/v7fs_io_user.c \
src/sys/fs/v7fs/v7fs_superblock.c src/sys/fs/v7fs/v7fs_superblock.h \
src/sys/fs/v7fs/v7fs_superblock_util.c src/sys/fs/v7fs/v7fs_vfsops.c \
src/sys/fs/v7fs/v7fs_vnops.c
 cvs rdiff -u -r1.108 -r1.109 src/sys/sys/disklabel.h
 cvs rdiff -u -r1.199 -r1.200 src/sys/sys/mount.h
 cvs rdiff -u -r1.232 -r1.233 src/sys/sys/vnode.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 

Re: CVS commit: src/sys/arch/evbppc/conf

[Matt Thomas]

On Jun 23, 2011, at 6:50 PM, Christos Zoulas wrote:

 In article 20110624004847.8a0ce17...@cvs.netbsd.org,
 Matt Thomas source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-
 
 Module Name: src
 Committed By:matt
 Date:Fri Jun 24 00:48:47 UTC 2011
 
 Modified Files:
  src/sys/arch/evbppc/conf: RB800
 
 Log Message:
 Turn on PAX_ASLR
 
 I am fine with that, just 2 comments.
 - to fully take advantage of ASLR you need MKPIE=yes so that the text
  and data segments get randomized too.

Already doing that.  Pretty certain I'm the only one using RB800 so ...
I want to do some timings to compare MKPIE=yes against MKPIE=no.

 - just using options PAX_ASLR is probably safer and you can then enable
  it with: sysctl -w security.pax.aslr.enabled=1

PAX_ASLR requires a value.

Re: CVS commit: src

[Matt Thomas]

On Jun 14, 2011, at 3:51 PM, Joerg Sonnenberger wrote:

 On Tue, Jun 14, 2011 at 08:51:48AM +0100, Iain Hibbert wrote:
 Hm, does the stack have any natural alignment requirements on amd64, such
 that a 10-char array actually occupies more space?
 
 AMD64 normally aligns to 16 Bytes.

So does powerpc.

Re: CVS commit: src/usr.bin/make

[Matt Thomas]

On Jun 10, 2011, at 4:57 PM, Simon J. Gerraty wrote:

 Module Name:  src
 Committed By: sjg
 Date: Fri Jun 10 23:57:39 UTC 2011
 
 Modified Files:
   src/usr.bin/make: meta.c
 
 Log Message:
 size_t on amd64 doesn't like %u, use a cast.

why not use %zu?

Re: CVS commit: src/sys/kern

[Matt Thomas]

On Jun 5, 2011, at 9:58 AM, Warner Losh wrote:

 
 On Jun 5, 2011, at 2:15 AM, Joerg Sonnenberger wrote:
 
 On Sat, Jun 04, 2011 at 02:47:53PM +0100, David Laight wrote:
 IIRC the arm ABI defines standard uses for a lot of the registers, one must 
 be for
 thread data - so could be used in the kernel for curlwp.
 
 Only for newer ARM generations. The old one have no native TLS register.
 
 That's ARMv5e and newer, right?

No, armv6 and latter.  And not all armv6 have them.  There is code in place to 
use them but none of the arm11s i have ever supported them.  I suppose armv7 
(cortex) should have them.

Re: CVS commit: src/sys/kern

[Matt Thomas]

 Thinking about SMP, both CURCPU() and curlwp could be the register - with the
 other being indirected from it.  I wonder which it used most?
 curproc should be readable from either.

Some MIPS CPUs have OS Scratch registers.  I use one to store curcpu since 
that is the one most useful in the exception handler.

I just made the changes so that PowerPC kernels will keep curlwp in %r13  (I 
choose r13 over r2 because r2 is used for TOC in the PPC64 ABI).  It has 
allowed me to remove several loads of curlwp in the assembly code let alone how 
many references in C code.

   textdata bss dec hex filename
6652040 3805600  212056 10669696 a2ce80 before
6642116 3805600  212056 10659772 a2a7bc after

That's nearly a reduction of 64KB.  The loading of %r13 with curlwp is free 
since in all cases, curlwp would have eventually been loaded into a register at 
some point.