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
On Thu, Oct 15, 2020 at 05:44:45PM +, Micha? G?rny wrote: > Module Name: src > Committed By: mgorny > Date: Thu Oct 15 17:44:45 UTC 2020 > > Modified Files: > src/distrib/sets/lists/tests: mi > src/etc/mtree: NetBSD.dist.tests > src/tests/sys: Makefile > Added Files: > src/tests/sys/x86: Makefile t_convert_xmm_s87.c > > Log Message: > Add tests for process_xmm_to_s87() and process_s87_to_xmm() This breaks all non-x86 builds, you need to consistently use the same conditions for the makefiles, set lists and mtree files. Probably easiest way out: create the directories always (but leave empty on non-x86). Alternative: do not use arch specific sub dirs. Martin
Re: CVS import: src/external/bsd/dhcpcd/dist
Hi Ryo
On 15/10/2020 02:23, Ryo ONODERA wrote:
dhcpcd-9.3.1 do not detect carrier with cdce(4) and urndis(4) devices.
dhcpcd-9.2.0 from pkgsrc-2020Q3 branch works without problems.
(Maybe 9.3.0 in NetBSD base worked for me.)
cdce and urndis have no "status" line in ifconfig command output.
Is this related to my problem?
Does this fix it?
diff --git a/src/if.c b/src/if.c
index 5f4edb86..deb5280b 100644
--- a/src/if.c
+++ b/src/if.c
@@ -198,10 +198,8 @@ if_is_link_up(const struct interface *ifp)
{
return ifp->flags & IFF_UP &&
- (ifp->carrier == LINK_UP ||
-(ifp->carrier == LINK_UNKNOWN &&
- !(ifp->options == NULL ||
- ifp->options->options & DHCPCD_LINK)));
+ (ifp->carrier != LINK_DOWN ||
+(ifp->options != NULL && !(ifp->options->options & DHCPCD_LINK)));
}
int
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
Re: CVS commit: src
On Wed, Oct 14, 2020 at 10:13:21PM +0100, Roy Marples wrote: > On 14/10/2020 20:07, Kimmo Suominen wrote: > > - not interfere with (static) IPv4 configuration > > How do you expect > ifconfig_vioif0='dhcp rtsol' > to work? When I added the code for the rtsol keyword, I did not imagine that it would be used with the dhcp keyword. In other words, I would have considered that an invalid configuration (among the many other invalid configurations you can make and that won't be checked against). However, it would be cool if that worked. Is there a better way to avoid having dhcpcd break a static IPv4 configuration? Using the rtsol keyword should neither enable DHCP for IPv4 nor enable IPv4LL address autoconfiguration. I've adjusted the way dhcpcd gets started by rtsol: it was not necessary to use nodhcp6 or ipv6ra_noautoconf. It was just part of how I got the network configuration to work again after upgrading to a current that no longer has in-kernel RA processing. Once it worked I didn't change it further. So now the O and M flags should no longer be ignored. > > I also think it is very good that with this change we once again > > have backwards compatibility for configuring static network > > addressing. > > We've never lost it. This is where we seem to have a difference in experience. For me the IPv4 configuration was broken. Kind regards, + Kimmo
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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. > > If we go this route, we should make the relevant procfs nodes independent > of -o linux. that would be fine by me. 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 :) .mrg.
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
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. If we go this route, we should make the relevant procfs nodes independent of -o linux. Martin
re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Tue Oct 13 07:12:00 UTC 2020 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c > > Log Message: > Reduce diff with upstream a bit. > No functional changes. 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. thanks! .mrg.
