In a poudriere jail, during a bulk run, what is the status of /etc/os-release supposed to be?
I tried to look via bulk with -i and what I saw via interactive commands was: # ls -ldT /etc/os-release lrwxr-xr-x 1 root wheel 21 Dec 6 00:48:55 2019 /etc/os-release -> ../var/run/os-release # ls -laT /var/run/ total 28 drwxr-xr-x 5 root wheel512 Dec 6 00:50:02 2019 . drwxr-xr-x 24 root wheel512 Mar 9 07:41:50 2019 .. drwxr-xr-x 2 root wheel512 Mar 9 07:41:50 2019 dhclient -r--r--r-- 1 root wheel173 Dec 6 00:50:01 2019 ld-elf.so.hints drwxrwx--- 2 root network 512 Mar 9 07:41:50 2019 ppp -rw-r--r-- 1 root wheel197 Dec 6 00:50:02 2019 utx.active drwxr-xr-x 2 root wheel512 Mar 9 07:41:50 2019 wpa_supplicant So no /var/run/os-release to find: # more /etc/os-release /etc/os-release: No such file or directory This was based on (from outside that bulk session): # poudriere version 3.3.99.20190828 # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH FBSDcortexA53jail 13.0-CURRENT arm64.aarch64 null 2018-11-18 15:32:34 /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud where what is at the PATH was based on: installworld distrib-dirs distribution DB_FROM_SRC=1 DESTDIR=/usr/obj/DESTDIRs/clang-cortexA53-installworld-poud (for a head -r355027 based context). This would appear to mean that port builds should not be trying to use /etc/os-release because /var/run/os-release is not established in poudriere-devel bulk build contexts? I will note that clang-cortexA53-installworld-poud was built via an amd64->aarch64 cross build, in case that matters for some reason. ( clang-cortexA53-installworld-poud/ was copied to the aarch64 system it was intended for. Both contexts use the /usr/obj/DESTDIRs/ style path prefix. ) I'm not trying to use /etc/os-release directly. I was just curious what it would appear to contain in such a context. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel module code coverage
On Thu, Dec 5, 2019 at 8:38 AM Ed Maste wrote: > > > > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > > > coverage information from the kernel. > > > > > That's part of Matt Macy's gcov project, right?. > > No, /dev/kcov is independent of, and predates, Matt Macy's work. It > provides broadly the same sort of information, but not using the same > interface. GCOV also depends on GCC - probably limiting its potential use cases largely to vendor CI. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel module code coverage
> > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > > coverage information from the kernel. > > > That's part of Matt Macy's gcov project, right?. No, /dev/kcov is independent of, and predates, Matt Macy's work. It provides broadly the same sort of information, but not using the same interface. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
