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...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
