Date: Wed, 24 Feb 2016 12:27:54 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: RF_CACHEABLE flag Message-ID: <20160224102754.GK91220@kib.kiev.ua> In-Reply-To: <CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com> References: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com> <20160222121836.GH91220@kib.kiev.ua> <CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: > This really isn't much different from bus_space_map() conceptually. > The work involved is pretty much the same, and if this route is deemed > the Wrong Way(TM), I'll go that route. > > Grepping through sys/, only x86 currently implements > pmap_change_attr(), and arm has the declaration but no definition that > I could see. Writing it wouldn't be difficult of course, there's just > not much compelling case for it right now. But, yes, either of these > alternatives are acceptable, and I had explored it. Seeing John > Baldwin's comment on the phab review, it looks like he wants to go a > different (parallel) direction. If this was not clear from my reply, I did not objected against RF_CACHEABLE, but was more to highlight weird needs of seemingly simple architecture, which are close to RF_CACHEABLE stuff. And, I think that architectures that care about caching modes, should do provide real pmap_change_attr() implementation. This might be important e.g. if drm is brought up on these platforms.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160224102754.GK91220>