Hi Brian, >>>> --- >>> Mesh Command >>> ============ >>> >>> Command Code: 0x0043 >>> Controller Index: <controller index> >>> Command Parameters: Opcode (1 Octet) >>> Command parameters (Variable) >>> Return Parameters: Status (1 Octet) >>> Opcode (1 Octet) >>> Return parameters (Variable) >>> >>> Mesh Event >>> ========== >>> >>> Event Code: 0x0026 >>> Controller Index: <controller index> >>> Event Parameters: Subevent (1 Octet) >>> Even parameters (variable) >>> >>> This would map 1:1 to the HCI mesh commands and events with the tiny >>> modification that the event prefix is stripped from the Mesh Event >>> and not provided and with the Mesh Get Options command issued it >>> would be mapped to event prefix length of zero. >>> >>> And then only a settings 16 Mesh would be needed. Or we make the >>> command and event only available when HCI mesh commands are actually >>> supported. That is something that would needs to be discussing. In >>> general, we have not had limited commands based on hardware >>> functionality, but these two would be special since they are vendor >>> specific commands in the first place. >>> >>> For the kernel side we only have the the driver provide the mesh HCI >>> opcode and run Mesh Get Options once to retrieve the firmwares event >>> prefix so that it can be zeroed out by the MGMT commands and events. >>> >>> With that comments? Thoughts? >> >> Well, while this approach could work. The advantage is the access to >> command complete and comand status events. But then having an >> independent mesh daemon (also ell based) may become problematic. >> Also, putting actual mesh access layer messages via management socket >> is a bit questionable: my understanding is that mgmt socket is mainly >> for control and configuration messsages. >> > > I think if we arrive at a position where we need "Command Complete" style feedback to User Space (if/when we get Controllers natively aware of Mesh), we should use an Ancillary (CMSG) response with an Empty Payload message on the same socket. This "Single Socket" model allows us to keep "Sequence of Events" better than using the MGMT interface... and as Inga noted, with a separate Mesh Daemon, we make it possible to have a much leaner "Mesh Only" usage model, without the User Space baggage of BR/EDR/LP infrastructure. the command complete is really just for flow control and return parameter transport. And we can still have a separate mesh daemon even with mgmt. Meaning you would still open a separate mgmt socket. And you need to do that anyway to list all available controllers and find the one that supports mesh. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
