On Sat, 2019-11-30 at 11:25 -0800, Enji Cooper wrote: > > On Nov 30, 2019, at 11:01 AM, Warner Losh <i...@bsdimp.com> wrote: > > > > On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper <yaneurab...@gmail.com > > <mailto:yaneurab...@gmail.com>> wrote: > > > > > On Nov 30, 2019, at 10:03 AM, Warner Losh <i...@bsdimp.com > > > <mailto:i...@bsdimp.com>> wrote: > > > > > > > > > > > > On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper < > > > yaneurab...@gmail.com <mailto:yaneurab...@gmail.com>> wrote: > > > > > > > On Nov 27, 2019, at 6:32 PM, Scott Long <sco...@freebsd.org > > > > <mailto:sco...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
