Re: openbmc Digest, Vol 32, Issue 32

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2018-04-13 at 13:11 +0800, Wang, Haiyue wrote:
> 
> On 2018-04-13 12:43, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-04-12 at 16:42 +0800, Wang, Haiyue wrote:
> > > I means the device tree merge time, putting things in kernel need long time
> > > to be passed code review. And people may want to export different range of
> > > registers, then they need to change the device tree, the development cycle
> > > may be long.
> > 
> > But that's not a big issue in practice though, you don't*need*  all
> > your device-trees to be upstream and up to date especially if it's
> > stored separately from the kernel.
> > 
> > Keep in mind this should be strictly limited to a few registers that
> > need that sort of manipulation, maybe a handful or two, that's it.
> > 
> > Most things need proper kernel drivers.
> > 
> 
> Understood, NOT exposing like /dev/mem makes sense for security

Not just security. It's also plain gross ;-)

It also means it's hard to locate which pieces of your userspace may
contain chip revision specific stuff.

If something changes, you get a nice error bcs the named file is absent
rather than whacking the wrong register with underterminate results.

The naming also makes the code more comprehensible & grep'able

You also have an atomicity problem is the same register contains
multiple things that several fields (kernel, userspace) try to modify
at the same time, etc etc etc...

It's never great to have userspace bang at the registers so directly.

etc etc etc..

A minimum of abastraction is much more preferable in these cases.

Cheers,
Ben.