openbmc Digest, Vol 32, Issue 32

[Wang, Haiyue]

On 2018-04-13 13:41, Benjamin Herrenschmidt wrote:
> 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.

Yes, absolutely agree with this point. Another big thing I missed. ;-)

> etc etc etc..
>
> A minimum of abastraction is much more preferable in these cases.
>
> Cheers,
> Ben.

Very appreciate your time to talk more about this design.

Thank you.

BR,

Haiyue