Hello Gustavo, > > MCAP in kernel gives zero-copy communication and just one socket to the > HDP API. The better of both UNIX socket and pipes options. > That's right I agree with you, but the main question here is not based in hiding MCAP reconnection, because future profiles using MCAP may be concern about above reconnection. Please, remember that nothing about hiding reconnections are mentioned in MCAP specification. However, reconnection are exposed as deseable capability in MCAP that upper profiles can use. In other hands, in particular case of HDP, we want to hide reconnection process to application layer because ISO/IEEE11073-20601 is transport agnostic, that means for example, a manager or agent sending or receiving APDUs don't be concern about such issues in transpiort layer (neither MCAP nor HDP). As you can see, the problem isn't in MCAP but in HDP<-->App to achieve reconnection transparency. That's is better explained in ISO/IEEE11073-20601 and some references can be found in HDP white paper. > > That semantics would be implemented in MCAP part. The HDP profile code itself is (or should be) free from these worries. > > > > Moving MCAP to kernel hides the complexity from userspace HDP profile, but it continues to exist. Then I worry about more complex debugging, dependency on kernel version (or need to put efforts on backporting). MCAP sits above L2CAP, not besides it. > > The complexity will exist anyway, I'm proposing a less complex option. > Is not that complex change the L2CAP channels used by the MCL inside the > kernel. Between all the proposed options to handle reconnection it > looks the less complex one. > > We should not care about backporting now. We are working directly > with upstream and upstream is what really matters here. :) > > You will depend on kernel version anyway since ERTM is inside the > kernel. About backport if you backport ERTM, then backport MCAP will be > easy. > > Also MCAP will keep sitting on top of L2CAP, that won't change. > > > > > I acknowledge that it would work, but honestly I prefer to see things being moved to the outside of the kernel than to the inside :) > > The real question here is where MCAP will fit better. And where it adds > less complexity to its users. >From my point of view we should avoid implement MCAP in kernel space for the same reason exposed by Jose Antonio and Elvis in other emails. IMHO hidding reconnections in MCAP is not an good reason to implement it in kernel space because transparency is required in HDP nor in MCAP. If you hide reconnection to upper profiles in MCAP, you are closing the door to future specifications if they require doing aditional precessing when a reconnection takes place in MCAP. Thanks for your comments. Regards, -- 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
