> On Nov 30, 2019, at 11:01 AM, Warner Losh <[email protected]> wrote: > > On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper <[email protected] > <mailto:[email protected]>> wrote: > >> On Nov 30, 2019, at 10:03 AM, Warner Losh <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper <[email protected] >> <mailto:[email protected]>> wrote: >> >> > On Nov 27, 2019, at 6:32 PM, Scott Long <[email protected] >> > <mailto:[email protected]>> 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... _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
