Re: CVS commit: src/sys/conf

2020-03-03 Thread Paul Goyette

On Wed, 4 Mar 2020, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Wed Mar  4 02:20:57 UTC 2020

Modified Files:
src/sys/conf: files

Log Message:
mips64 has compat_netbsd32 but cannot have exec_aout; all other users
of compat_netbsd32 need exec_aout

Addresses PR kern/55037.

XXX pullup-9


Also XXX pullup-8



Re: CVS commit: src/sys/kern

2020-03-03 Thread Andrew Doran
On Tue, Mar 03, 2020 at 02:55:16PM -0500, Christos Zoulas wrote:

> Module Name:  src
> Committed By: christos
> Date: Tue Mar  3 19:55:16 UTC 2020
> 
> Modified Files:
>   src/sys/kern: vfs_syscalls.c
> 
> Log Message:
> don't skip the rdir check for the lazy case; breaks chroot df(1) hiding.

That's likely my mistake.  Thank you.

Andrew


Re: CVS commit: src/lib

2020-03-03 Thread Taylor R Campbell
> Date: Tue, 03 Mar 2020 20:05:14 +1100
> from: matthew green 
> 
> thanksand can you please have this pulled up to other
> branches it's present on.

Already done:

https://releng.NetBSD.org/cgi-bin/req-9.cgi?show=756
https://releng.NetBSD.org/cgi-bin/req-8.cgi?show=1513


Re: CVS commit: src/sys/dev

2020-03-03 Thread Christos Zoulas
Yes, I thought about providing an ioctl to do this, but it would mean that 
everything
that talks to those devices would need to be modified to issue the ioctl. Raw 
mode
means to call the underlying uhidev write which is the raw usb writes instead of
using the report mechanism. My devices did not work using the report mechanism.
Linux provides a /dev/uhidrawN node.

christos

> On Mar 2, 2020, at 11:26 PM, matthew green  wrote:
> 
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Mar  2 18:15:29 UTC 2020
>> 
>> Modified Files:
>>  src/sys/dev/hid: hid.h
>>  src/sys/dev/usb: uhid.c
>> 
>> Log Message:
>> Add fido constants, and turn hid "raw" mode for fido devices.
> 
> this is gross.
> 
> please don't put device specific stuff into uhid like this.
> 
> without really understanding, it seems that there should be
> a uhid ioctl to enable this mode, and then your userland code
> sets it, instead of this hack.
> 
> also, please actually explain what this "raw" mode means.  is
> there perhaps a way to avoid this entirely?  what's the real
> underlying need here..?
> 
> 
> .mrg.



signature.asc
Description: Message signed with OpenPGP


re: CVS commit: src/sys/dev

2020-03-03 Thread matthew green
Martin Husemann writes:
> On Tue, Mar 03, 2020 at 03:26:47PM +1100, matthew green wrote:
> > without really understanding, it seems that there should be
> > a uhid ioctl to enable this mode, and then your userland code
> > sets it, instead of this hack.
> 
> Or make uhid not attach at all on FIDO devices and instead use ugen from
> userland?

no... see below.

> Or solve the long standing "every usb devices should be able to eject
> its driver and be used as ugen instead" problem, see also the various
> JTAG devices showing up as dual uftdi and you need to override in your
> kernel config like:
> 
> # GuruPlug JTAG debug interface
> ugenif* at uhub? vendor 0x9e88 product 0x9e8f interface 0 flags 1

yes.. this.  but not for this device :-)

> Most devices go via uhid to make userland access easy on windows, but for us
> it makes no real difference.

in this instance, i would rather not use ugen since it's such
a very simple API need.  ugen == generic access, and it's hard
with our system to protect against that.  usb device numbers
are volatile, so you can't simply trust chmod in /dev.

uhid is a fairly isolated interface, and i think it's right to
use a real driver here than ugen:

crw---  1 root  wheel  64, 0 Feb 27 09:08 /dev/ugen0.00
crw-rw-rw-  1 root  wheel  56, 0 Feb 27 09:08 /dev/uhid0

ie, your method would require being root or opening up all
the usb devices...


.mrg.


re: CVS commit: src/lib

2020-03-03 Thread matthew green
> Committed By: riastradh
> Date: Tue Mar  3 04:20:50 UTC 2020
> 
> Modified Files:
>   src/lib: Makefile
> 
> Log Message:
> Remove unfinished hack I accidentally committed in 2017.
> 
> This caused make to unconditionally take ages running useless
> submakes in every subdirectory.  Accidentally committed during the
> MKCRYPTO option removal when I was presumably experimenting with
> automating library dependency generation in lib.
> 
> Should shave a few seconds at least off every build!

more than a few!  it takes at least 2 seconds on a really fast
system to startup in this subdir, and we enter here a bunch
of times each build, about twice as many on MKCOMPAT=yes
platform...  and it's serialised.  i'll test.. this could be
as much as 1% of the amd64 build time!

thanksand can you please have this pulled up to other
branches it's present on.


.mrg.