From owner-svn-src-all@freebsd.org Sat Apr 20 18:59:43 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A24861572E08; Sat, 20 Apr 2019 18:59:43 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEF966E0CF; Sat, 20 Apr 2019 18:59:42 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x3KIxdwf023813; Sat, 20 Apr 2019 11:59:39 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x3KIxd9J023812; Sat, 20 Apr 2019 11:59:39 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201904201859.x3KIxd9J023812@gndrsh.dnsmgr.net> Subject: Re: svn commit: r346441 - in head/sys/modules: em fusefs iavf In-Reply-To: To: Warner Losh Date: Sat, 20 Apr 2019 11:59:39 -0700 (PDT) CC: Alan Somers , Justin Hibbits , src-committers , svn-src-all , svn-src-head Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: EEF966E0CF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.85 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.85)[-0.847,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 18:59:43 -0000 > On Sat, Apr 20, 2019, 7:47 AM Alan Somers wrote: > > > On Sat, Apr 20, 2019 at 7:23 AM Justin Hibbits > > wrote: > > > > > > > > > > > > On Sat, Apr 20, 2019, 08:21 Alan Somers wrote: > > >> > > >> On Sat, Apr 20, 2019 at 6:58 AM Justin Hibbits > > wrote: > > >> > > > >> > > > >> > > > >> > On Sat, Apr 20, 2019, 07:51 Alan Somers wrote: > > >> >> > > >> >> Author: asomers > > >> >> Date: Sat Apr 20 12:51:05 2019 > > >> >> New Revision: 346441 > > >> >> URL: https://svnweb.freebsd.org/changeset/base/346441 > > >> >> > > >> >> Log: > > >> >> Use symlinks for kernel modules rather than hardlinks > > >> >> > > >> >> When aliasing a kernel module to a different name (ie if_igb for > > if_em), > > >> >> it's better to use symlinks than hard links. kldxref will omit > > entries for > > >> >> the links, ensuring that the loaded module has the correct name. > > >> >> > > >> >> > > >> > > > >> > > > >> > Thanks! This should fix installkernel on my POWER9. > > >> > > > >> > - Justin > > >> > > >> What's the problem with your POWER9? Is that one of those msdosfs > > >> /boot systems? If so, I don't think this will fix it. msdosfs > > >> doesn't support either symlinks or hardlinks. Or is there some other > > >> problem? > > >> -Alan > > > > > > > > > Yes it is. Well that's a bummer then. I thought we faked symlinks on > > msdosfs, but on second thought not sure how well would do that. > > > > > > - Justin > > > > We should probably just remove the offending links on ppc, then. The > > only harm is that after upgrading, ppc users would have to replace > > fuse_load="YES" with fusefs_load="YES". > > > > We should only do the Intel links on those platforms that have legacy users > that need the old names. We should also only support the old names for one > release or so. IIRC this was done so that the dropping of one of the drivers in ^head could be merged back to ^stable. It probably should of been killed in ^head after that fact, but if I recall the values correctly it was @head=12 and merged to @stable=11. We would need to dig those facts out, but yes, please, this link should be killed and cleaned up quickly as it creates almost as many problems as it solved. > Warner -- Rod Grimes rgrimes@freebsd.org