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