On Mon, 2017-03-20 at 13:18 +0000, Will Deacon wrote:
> > The thing is, this *isn't* an architecture-specific interface where you
> > get a clean slate. It's a cross-platform interface. Legacy and horrid,
> > sure. But it does you no harm.

> I don't agree with that: it provides (privileged) userspace with a way to
> map non-prefetchable BARs using write-combining memory attributes, which
> could lead to mismatched memory attributes against a kernel mapping of the
> same BAR and is something that you can't achieve using the sysfs API.

I think that's just a bug. I'll add it to my list. We shouldn't be
allowing a WC mapping on a non-prefetchable resource, should we?

For that matter, I think it allows you mmap a range of MMIO addresses
that correspond to an I/O BAR, and on platforms which allow
pci_mmap_io, the converse. That seems... suboptimal.
 
> > What *else* don't you like having in /proc? Shall we have a clean slate
> > and eliminate *everything* other than actual processes from /proc for
> > the next architecture we add to the tree? If not, why not?
> It's not about what we like and don't like in /proc, it's about not
> promoting legacy that we don't need. If somebody actually needs the /proc
> interface, fine, we can support it. But all the people asking for this have
> been concerned solely about the sysfs interface, so I'd just like the two
> divorced from each other so that we can provide what people are asking for
> without pulling in a deprecated interface at the same time.
> 
> This should be straightforward.

Sure, but fairly much orthogonal. I'll roll it in. It's fairly much in
the noise now I'm this far down the rabbithole...