Hi Ketan, Just a suggestion - you probably don't want to be passing MCTP messages over dbus - this is something we learnt from the IPMI implementation. The current design of the mctp-demux-daemon (included in the libmctp codebase) is intended to provide an interface that will be easy to migrate to a future kernel implementation (ie., using sockets to pass MCTP messages), and allows multiple applications to be listening for MCTP messages of different types. Regards, Jeremy On 14 January 2020 1:54:49 pm AWST, "Khetan, Sharad" wrote: >Hi Deepak, > >On 13/01/20 10:23 PM, Khetan, Sharad wrote: >> Hi Andrew, >> >> On Thu, 9 Jan 2020, at 12:27, Andrew Jeffery wrote: >>> >>> >>> On Sat, 21 Dec 2019, at 10:45, Khetan, Sharad wrote: >>>> Hi Andrew, >>>> Sorry for late response. >>>> The plan is to have MCTP in user space. >>>> >>> >>> How are you handling this then? mmap()'ing the BAR from sysfs? >> >>> Sorry, let me put my brain back in, I was thinking of the wrong side >of the BMC/Host MCTP channel. How much were you planning to do in >userspace on the BMC? As in, are you planning to drive the BMC's PCIe >MCTP controller from userspace (presumably via /dev/mem)? >> >> >> For implementation on the BMC, we agree that it's better to do it in >kernel (and as you mentioned - use consistent interface to upper >layers, provide another transport). However, given the time needed to >implement things in kernel (and the review after), we are starting with >a short term solution. We will be implementing MCTP (protocol elements) >in user space, along with a low level MCTP PCIe driver just to push >bits on PCIe. Iwona is working on this and should be able to describe >the exact primitive. > >Do you plan to do the user-space work as an extension to/reusing >components from openbmc/libmctp? > >Thanks, >Deepak > >Yes we plan to reuse and extend the libmctp, support PCIe as well as >SMBus bindings. We plan to use d-bus extensions to existing libmctp. >That said, we will know the exact extent of reuse/modifications when we >really start implementing. > >We are implementing this for AST 2600 (will not support any workarounds >for AST 2500 bug). > >@Andrew, Thanks for your response. > >Thanks, >Sharad >