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

[Warner Losh]

On Sat, Nov 30, 2019 at 11:58 AM Enji Cooper <yaneurabeya at gmail.com> wrote:

>
> On Nov 30, 2019, at 10:03 AM, Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Sat, Nov 30, 2019 at 10:47 AM Enji Cooper <yaneurabeya at gmail.com>
> wrote:
>
>>
>> > On Nov 27, 2019, at 6:32 PM, Scott Long <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
>> >
>> > Log:
>> >  Remove the trm(4) driver
>> >
>> >  Differential Revision:       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 :)

Warner