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

[Enji Cooper]

> 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...