svn commit: r355164 - in head: . share/man/man4 sys/amd64/conf sys/conf sys/dev/trm sys/i386/conf sys/modules sys/modules/trm

[Ian Lepore]

On Sat, 2019-11-30 at 11:25 -0800, Enji Cooper wrote:
> > On Nov 30, 2019, at 11:01 AM, Warner Losh <imp at bsdimp.com> wrote:
> > 
> > On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper <yaneurabeya at gmail.com
> >  <mailto:yaneurabeya at gmail.com>> wrote:
> > 
> > > On Nov 30, 2019, at 10:03 AM, Warner Losh <imp at bsdimp.com
> > > <mailto:imp at bsdimp.com>> wrote:
> > > 
> > > 
> > > 
> > > On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper <
> > > yaneurabeya at gmail.com <mailto:yaneurabeya at gmail.com>> wrote:
> > > 
> > > > On Nov 27, 2019, at 6:32 PM, Scott Long <scottl at FreeBSD.org
> > > > <mailto:scottl at FreeBSD.org>> wrote:
> > > > 
> > > > Author: scottl
> > > > Date: Thu Nov 28 02:32:17 2019
> > > > New Revision: 355164
> > > > URL: https://svnweb.freebsd.org/changeset/base/355164 <
> > > > https://svnweb.freebsd.org/changeset/base/355164>
> > > > 
> > > > Log:
> > > >  Remove the trm(4) driver
> > > > 
> > > >  Differential Revision:       
> > > > https://reviews.freebsd.org/D22575 <
> > > > https://reviews.freebsd.org/D22575>
> > > 
> > > Hi Scott,
> > >         I believe this driver was removed because it was impacts
> > > the CAM GIANT lock removal effort — is that true (I’m asking
> > > because the “why” behind the removal is unclear)?
> > > 
> > > Hi Enji,
> > > 
> > > We're trying hard to get rid of all Giant-locked drivers in the
> > > tree, either by updating or removal. Since sym(4) provides a
> > > super-set of trm(4) and we have recent-ish reports of sym(4)
> > > working, it makes sense to trim this driver from the tree. The
> > > specific cards it supports aren't all that popular, the couple-
> > > extra features that trm(4) gave over sym(4) aren't really that
> > > relevant today, and it's been years since trm has had good
> > > testing and maintenance.
> > 
> > Warner,
> > 	Thanks so very much for the info :). Glad to see this effort
> > taking place, since it’s very needed to modernize FreeBSD and
> > improve concurrency in the kernel, as well as reduce the overall
> > maintenance burden.
> > 
> > Giant isn't contending, but it's getting in the way of a cleanup of
> > the console / kbd system, as well as there being newbus issues in
> > highly dynamic systems. With TB and USB4 support on the horizon, we
> > need to finally clean that mess up.. I'll post a longer summary of
> > what's left. I have a 'doodle' tree that I'm separating out the
> > Giant usage to 'driver lock', kbd/console/ddb, newbus, sysctl, and
> > WTF is that protecting... I'm tempted to create wtf_lock() and
> > wtf_unlock(), but I'm not sure how well that would go over :)
> 
> Sounds great :D…
> -Enji
> 
> PS wtf_lock() would be amusing, but probably less of a good idea
> these days :D...

But naming is important... I was wondering the other day whether Giant
would have been misused and overused less if it had been named
splhigh_lock.

-- Ian