re: CVS commit: src/sys
matthew green writes: > > also, these updates to video(4) don't require a kernel bump > > so please revert that too. > > but this part could be done if you do it fast.. uvideo(4) as a module proves me wrong about this one too.. however, i'm looking at the changes and i'm not 100% convinced it's safe to simply replace this file as-is. - struct v4l2_pix_format is laid out differently - enum v4l2_buf_type <-> u_int32_t does not seem safe, in eg struct v4l2_buffer. i *think* it may be, but it won't work with eg, -fshort-enums now. - struct v4l2_rect width/height are now unsigned (probably ok?) - struct v4l2_window has a new member (global_alpha) ... this is enough for you to need to look at all of these closely to ensure you haven't broken binary compat. please look at all the structure layouts and ensure they aren't changed. thanks. .mrg.
Re: CVS commit: src/sys
matthew green wrote: >"Robert Swindells" writes: >> Module Name: src >> Committed By:rjs >> Date:Mon Aug 10 19:27:28 UTC 2020 >> >> Modified Files: >> src/sys/dev: video.c >> src/sys/dev/usb: uvideo.c >> src/sys/sys: videoio.h >> >> Log Message: >> Add some extra V4L ioctl() requests to latest V4L userland to work. >> >> Import sys/videoio.h from OpenBSD, this is just the Linux headers >> concatenated together. > >this seems very problematic in that you've added GPLv2 code >into src/sys/sys. It isn't GPLv2, it is dual licenced. The header was copied from OpenBSD. >please revert. The change was discussed on tech-kern. >also, these updates to video(4) don't require a kernel bump >so please revert that too. They change structures that are passed into the kernel.
re: CVS commit: src/sys
> > Import sys/videoio.h from OpenBSD, this is just the Linux headers > > concatenated together. > > this seems very problematic in that you've added GPLv2 code > into src/sys/sys. > > please revert. ah- i see it has dual-license, please ignore me. thanks to nia@ for the hint.. > also, these updates to video(4) don't require a kernel bump > so please revert that too. but this part could be done if you do it fast.. .mrg.
re: CVS commit: src/sys
"Robert Swindells" writes: > Module Name: src > Committed By: rjs > Date: Mon Aug 10 19:27:28 UTC 2020 > > Modified Files: > src/sys/dev: video.c > src/sys/dev/usb: uvideo.c > src/sys/sys: videoio.h > > Log Message: > Add some extra V4L ioctl() requests to latest V4L userland to work. > > Import sys/videoio.h from OpenBSD, this is just the Linux headers > concatenated together. this seems very problematic in that you've added GPLv2 code into src/sys/sys. please revert. also, these updates to video(4) don't require a kernel bump so please revert that too. .mrg.
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k
> May be we should also check other ports for similar gotcha proactively? good idea. no other gcc/config/*/*netbsd* files define the nasty STACK_BOUNDARY macro so hopefully we're good now. thanks! .mrg.
re: CVS commit: src/sys/arch
thanks! > XXX > Apply similar fixes to other m68k ports. yes...but also, a long-term project to consolidate all the almost-identical m68k code copied into each port would avoid this probably :-)
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k
On Mon, Aug 10, 2020 at 06:24:39 +, Rin Okuyama wrote: > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/m68k: netbsd-elf.h > > Log Message: > PR port-m68k/6 > > Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga, > when kernel is compiled by GCC8. This sounds eerily similar to port-macppc/54827 - there's quite a bit of confusion early on on my part there, but scroll to the last couple of mails. http://gnats.netbsd.org/54827 It looks like some logic changed in MI gcc8 that broke netbsd MD config headers and I wonder if you see the same problem here. For macppc the fix was also to undo the netbsd change to STACK_BOUNDARY in favor of PREFERRED_STACK_BOUNDARY. May be we should also check other ports for similar gotcha proactively? -uwe
