Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote: > I'm also one who feels hesitate to import Linux'ism into our basic > components. However, for this problem in particular, I still think > it is not a good choice to keep NetBSD support in driver-aarch64.c: > > (a) Our sysctl(3)-based interface is not compliant to any standards, > just like Linux's /proc/cpuinfo. But the latter is, unfortunately > for us, the de facto standard. It works properly in a chroot etc without needing new files. I would call that a big plus. Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Hi, (tech-toolchain@ added to cc) On 2020/10/16 1:49, Kamil Rytarowski wrote: On 15.10.2020 17:14, Rin Okuyama wrote: On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. ryo@ recently added additional /proc/cpuinfo support that should make this just work with the upstream version, but i haven't had chance to update and see if this is the case. I've confirmed that -mtune=native works fine at least for A53, even if all the local changes to driver-aarch64.c is reverted. I will commit it soon. If we go this route, we should make the relevant procfs nodes independent of -o linux. that would be fine by me. Nowadays, -o linux is turned on by default (unless nolinux is specified explicitly). Still, native apps probably should not depend on it. This needs MI changes to procfs, not MD to aarch64. Should we enable /proc/cpuinfo unconditionally? I'm against the policy of restoring the /proc dependency for this corner case in one application. We need to upstream the NetBSD specific patches to mainline GCC. I'm also one who feels hesitate to import Linux'ism into our basic components. However, for this problem in particular, I still think it is not a good choice to keep NetBSD support in driver-aarch64.c: (a) Our sysctl(3)-based interface is not compliant to any standards, just like Linux's /proc/cpuinfo. But the latter is, unfortunately for us, the de facto standard. (b) Because of (a), driver-aarch64.c is deeply depended on /proc/cpuinfo. Our NetBSD support code see diff to vendor branch here: http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/config/aarch64/driver-aarch64.c.diff?r1=1.1.1.7=1.10=h is something like a "glue code" which converts our convention to /proc/cpuinfo style. We already do this in procfs. Why twice? (c) I imagine that there would be little benefits for upstream to merge NetBSD support into their repository. If they will merge, I don't think the code is kept updated. (d) Only -march=native and -mtune=native depends on this feature. I'm OK with /proc/cpuinfo is left as is; only enabled when -onolinux is not specified. IMO, it is users' responsibility that such a additional feature fails with their non-standard system settings. In short, I'm worried about future when mrg@ or someone else have to maintain our glue code eternally, if this code is not reverted. Thanks, rin
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Date:Fri, 16 Oct 2020 04:07:31 + From:"Thomas Mueller" Message-ID: <20201016052422.e063084...@mail.netbsd.org> | Should I add ,linux to the end of the procfs line? You can, but it isn't needed these days -- I used to mount procfs twice, once without the linux option, on /proc, and once with, on /emul/linux/proc) but there seems to be little point in that any more (even though the linux /proc has a whole bunch of trash that has nothing to do with processes, and should be, and generally is, available from /kern ... /proc/cpuinfo is an example of that, though that one is missing from kernfs and should be added there). I do add "hidden" to the mount option list though, there's essentially no point in including /proc /kern /dev/pts (or anything else like those) in default df output (which is the only thing "hidden" generally affects). kre
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
Excerpt from Rin Okuyama: > Nowadays, -o linux is turned on by default (unless nolinux is > specified explicitly). Still, native apps probably should not > depend on it. > This needs MI changes to procfs, not MD to aarch64. Should we > enable /proc/cpuinfo unconditionally? My NetBSD system has no /kern and no /proc, do I need to mkdir these directories? I just did. kernfs and procfs were commented out in /etc/fstab . Do I need to revive, new /etc/fstab being as shown below, is this good now? Should I add ,linux to the end of the procfs line? I might want to run Linux programs. # NetBSD /targetroot/etc/fstab # See /usr/share/examples/fstab/ for more examples. NAME=WD2G19 / ffs rw,log 1 1 NAME=WD2G17 none swapsw,dp0 0 kernfs /kern kernfs rw ptyfs /dev/ptsptyfs rw procfs /proc procfs rw /dev/cd0a /cdrom cd9660 ro,noauto tmpfs /var/shmtmpfs rw,-m1777,-sram%25 Tom
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
On 15.10.2020 17:14, Rin Okuyama wrote: > On 2020/10/15 16:12, matthew green wrote: >> Martin Husemann writes: >>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. ryo@ recently added additional /proc/cpuinfo support that should make this just work with the upstream version, but i haven't had chance to update and see if this is the case. > > I've confirmed that -mtune=native works fine at least for A53, > even if all the local changes to driver-aarch64.c is reverted. > I will commit it soon. > >>> If we go this route, we should make the relevant procfs nodes >>> independent >>> of -o linux. >> >> that would be fine by me. > > Nowadays, -o linux is turned on by default (unless nolinux is > specified explicitly). Still, native apps probably should not > depend on it. > > This needs MI changes to procfs, not MD to aarch64. Should we > enable /proc/cpuinfo unconditionally? I'm against the policy of restoring the /proc dependency for this corner case in one application. We need to upstream the NetBSD specific patches to mainline GCC. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. ryo@ recently added additional /proc/cpuinfo support that should make this just work with the upstream version, but i haven't had chance to update and see if this is the case. I've confirmed that -mtune=native works fine at least for A53, even if all the local changes to driver-aarch64.c is reverted. I will commit it soon. If we go this route, we should make the relevant procfs nodes independent of -o linux. that would be fine by me. Nowadays, -o linux is turned on by default (unless nolinux is specified explicitly). Still, native apps probably should not depend on it. This needs MI changes to procfs, not MD to aarch64. Should we enable /proc/cpuinfo unconditionally? i had to write the netbsd version of that code twice so far. once for gcc 8.3 and 8.4, once for gcc 8.5 and 9.3, and i'd really rather avoid having to write another version :) Oh... Thank you very much for your hard works! Thanks, rin
