On 09/06/2017 04:56 AM, Brendan Higgins wrote:
On Thu, Aug 24, 2017 at 6:01 AM, Corey Minyard <miny...@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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
