linux-kernel - Re: [linux-usb-devel] HID bus prototype

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <461B6E4C.70008@gmail.com>
Date:	Tue, 10 Apr 2007 19:00:28 +0800
From:	Li Yu <raise.sail@...il.com>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	Li Yu <raise.sail@...il.com>, hongzhiyi@...ss.com.cn,
	yanghong@...ss.com.cn, Marcel Holtmann <marcel@...tmann.org>,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] HID bus prototype - 20070408

Jiri Kosina wrote:
> Hi Li,
>
> we have been discussing this with Marcel previously, and the decission was 
> to let the hidp code where it is right now, due to it being very closely 
> connected to the bluetooth network stack.
>   
That's OK.
>   
>> 	1. HID/Bluetooth support, ONLY FOR HIGHLY EXPERIMENT. I have no 
>>          any such device to test yet.
>>     
>
> I didn't have time yet to review the patch you sent previously, but I 
> don't still quite understand why does the transport layer matter here? The 
> generic HID layer, as it is in kernel now, makes an abstraction in a way 
> that the HID-specific drivers should not care about the underlying 
> transport layer.
>
>   
Here is my reason for supply such hid_transport data structure:

As before, we only have one driver for each transport layer, IOW, the
common driver. In this case, we really need not such transport data
structure. However, there are many driver in one transport layer after
HID bus come, these drivers at the same transport layer implementation
would like share some something each other, these live in common driver
before. If we did not add such transport data structure, we must find
one related driver, and clone it, I think that is not good idea.

In fact, even now, the HID processing logic still do not take care of
which transport layer works under it, the cost just is increasing some
pointer reference operations.

>> 	I am sorry for it is not in patch form.
>>     
>
> That's quite unfortunate. I'll try to review it nevertheless, but it'd be 
> much more convenient if you manage to send a patch.
>
>   
OK, I will post the patch for 2.6.21-rc6-mm1 later. You are recommended
to wait to review that.

My friend yanghong buy a new bluetooth mouse, so I can test bluetooth
nowadays, Thanks him here. :D

Good luck.

- Li Yu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/