[RFC v1 1/4] ipmi_bmc: framework for BT IPMI on BMCs

[Corey Minyard]

On 09/06/2017 04:56 AM, Brendan Higgins wrote:
> On Thu, Aug 24, 2017 at 6:01 AM, Corey Minyard <minyard at acm.org> wrote:
>>
>> If you just need the ability to catch a few commands in the kernel, what you
>> have is fairly complicated.  I think a simple notifier called from every
>> driver
>> would provide what you needed with just a few lines of code.
> What do you mean by a simple notifier called from every driver? I think what
> I have here is pretty simple. I think regardless of how we do routing, having
> a common framework for low level IPMI hardware interfaces to implement
> is pretty useful, even if it is only used to make a common dev file interface.
>

I'm talking about maybe 10 lines of code to do this.  The device 
interface would
call  xxx_notifier_call_chain() for each message, and depending on the
return value it would send the message up or drop it.  Every piece of 
code that
cared about IPMI host messages would call 
xxx_notifier_chain_register/unregister.
That would be it.

>> As far as moving all the message routing to the kernel, my (fairly
>> uneducated)
>> opinion would be that it's a bad idea.  It's a lot of complexity to put in
>> there.
>> I can see some advantages to putting it there: it's simpler to interact with
>> than
>> a userspace daemon and it gives consistent access to kernel and userspace
>> users.  But I don't know your whole design.
> How about we focus on getting a common framework for the hardware
> interfaces to implement? This way at least all of the hardware interfaces
> are exposed the same way (similar to what you did on the host side). We
> then at least have something to build on.

The device interface you have in patch 2 provides that, and I think 
that's a good
thing.  Most other drivers like this have something similar.

What you have for the message routing seems like massive overkill for 
catching
a few messages in the kernel.  It's really more at the level that you 
have lots of
users in and out of kernel and you need to handle routing of all these 
messages.

The IPMI client side message handler is there for two reasons:  You have 
to be able
to route messages down and back up to all the users, and those users may be
sending the same commands.  And you need some way to allow multiple users
to send on the IPMB and return the responses to those users.  And then 
there's
that LAN routing thing.  It's a lot more complexity than I like, and it 
occasionally
causes me problems.  I would have preferred to have something simpler.

-corey