Hi Gustavo, El Monday 17 May 2010 23:38:38 Gustavo F. Padovan escribió: > Hi, > > * João Paulo Rechi Vita <jprvita@xxxxxxxxx> [2010-05-17 18:17:58 -0300]: > > <snip> > > > On Mon, May 17, 2010 at 11:54, José Antonio Santos Cadenas > > > > <jcaden@xxxxxxxxxxxx> wrote: > > > array GetDataChannelFileDescriptor(uint16 mdlid) > > > > Wouldn't be better to pass the fd through the LinkConnected call on > > Agent? Doing it here allows any process to get the fds. > > I was thinking about the MCAP in kernel implementation, my conclusion is > that we can solve one of the biggest problem of HDP API if we do it in > kernel: the transparency of MCAP reconnection. HDP will open an MCAP > socket and pass it to the user(IEEE app). Then if we need a > reconnection, MCAP will transparently reconnect changing the L2CAP > channel to transmit the data without the need to change the socket > opened with the userspace. This that you proposed is something that we thought when we started with MCAP/HDP. We finally decided to put MCAP outside the kernel because of the following reasons: - The first and the most important is that everything that can be done in user space should be done in user space. We talked about this issue in the list some time ago and Marcel suggested us that if MCAP doesn't have interaction with other kernel subsystems, it should be implemented outside the kernel. You can read these mails here [1]. Basing on our experience with MCAP that's true, MCAP does not interact with any kernel subsystem. - An other reason is that reconnections *should not* be transparent at MCAP level. Any profile using MCAP should be concerned about the data channel disconnection and reconnection. In the case of HDP reconnections should be hide to the application layer. - Finally the kernel implementation will require a very complex API because MCAP require notifying lots of events some of the requiring a response(i.e., incoming mdl connection that need a response from the next level using MCAP with the configuration). Probably MCAP in the kernel space will be so complicated to used an you will require a user space library that make simpler the use of this API. > > Keep the MCAP socket open means that we are keeping the MCL state for > further reconnection. > > Doing it inside the kernel removes a big amount of complexity of HDP and > IEEE profiles, since we won't need any pipe or change of fd. That could > be a killer feature to make it in the kernel. > > Any comments? Is this reasonable? In our opinion reconnections are not a reason to implement MCAP in kernel space because reconections should not be transparent at this level. > > <snip> [1] http://www.spinics.net/lists/linux-bluetooth/msg03001.html -- 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
