Hi Mat, On Thu, Jul 26, 2012 at 08:04:11AM -0700, Mat Martineau wrote: > >>-static void __l2cap_connect(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, > >>- u8 *data, u8 rsp_code, u8 amp_id) > >>+static struct l2cap_chan *__l2cap_connect(struct l2cap_conn *conn, > >>+ struct l2cap_cmd_hdr *cmd, > >>+ u8 *data, u8 rsp_code, u8 chan_id) > > > >Do you think chan_id is better then amp_id? At least for channel connect amp_id > >looks better. > > > > When we were defining the socket option API, Marcel preferred > "channel policy" over "AMP policy", so I tried to keep terminology > more generic in this code as well. That might not have been the > correct decision. I'm fine with anything: amp_id, chan_id, > controller_id, ... I think amp_id and controller_id (or even remote_amp_id) are better names since this is "the identifier of the Controller on the remote device obtained via an AMP Manager Discover Available AMPs request." chan_id is kind of identifier of a channel, a name would be messed with CID which is already used for other purposes. I think the name channel policy is also OK since it is a policy of a channel (for each channel we might have different policy). Best regards Andrei Emeltchenko -- 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
