This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision |
| andriygapon:avgsyscons [2011/12/18 10:52] – wip AndriyGapon | andriygapon:avgsyscons [2016/07/21 11:02] (current) – Move user articles under user heirarchy KubilayKocak |
|---|
| The problem with ''%%ukbd%%'' is that it has to interact with rather complex hardware compared to AT compatible keyboard controller, besides also unlike the AT keyboard controller the USB controller can be shared with rather non-trivial peripherals and their drivers. By necessity the underlying USB subsystem must use multiple threads in most of the contexts. Thus the ''%%ukbd%%'' driver must honor concurrency and locking strategies of the USB subsystem when the USB threads are active. | The problem with ''%%ukbd%%'' is that it has to interact with rather complex hardware compared to AT compatible keyboard controller, besides also unlike the AT keyboard controller the USB controller can be shared with rather non-trivial peripherals and their drivers. By necessity the underlying USB subsystem must use multiple threads in most of the contexts. Thus the ''%%ukbd%%'' driver must honor concurrency and locking strategies of the USB subsystem when the USB threads are active. |
| |
| Summary. Context 1 is not applicable to the ''%%ukbd%%''. In contexts 3 and 4 the USB threads do not run, so the ''%%ukbd%%'' doesn't have to acquire any locks (in fact in context 3 it must not acquire any locks) and also it must directly go all the way to hardware via direct calls. In context 2 the ''%%ukbd%%'' must acquire the necessary locks, the ''%%Giant%%'' currently, if it is called via routines related to polling. It's important to note that in this context the ''%%ukbd%%'' driver works in interrupt driven mode internally. The USB threads are running and they perform the actual interaction with the hardware. So the ''%%ukbd%%'' must not access the hardware directly. Also, if it has to sleep/wait for the USB threads, then it should release the ''%%Giant%%'' while doing so, so that the USB threads can interact with the ''%%ukbd%%'' under ''%%Giant%%'' protection. Context 5 should be mostly similar to context 2. | Summary. Context 1 is not applicable to the ''%%ukbd%%''. In contexts 3 and 4 the USB threads do not run, so the ''%%ukbd%%'' doesn't have to acquire any locks (in fact in context 3 it must not acquire any locks) and also it must directly go all the way to hardware via direct calls. In context 2 the ''%%ukbd%%'' must acquire the necessary locks, the ''%%Giant%%'' currently, if it is called via routines related to polling. It's important to note that in this context the ''%%ukbd%%'' driver works in interrupt driven mode internally. The USB threads are running and they perform the actual interaction with the hardware. So the ''%%ukbd%%'' must not access the hardware directly. Also, if it has to sleep/wait for the USB threads, then it should release the ''%%Giant%%'' while doing so, so that the USB threads can interact with the ''%%ukbd%%'' under ''%%Giant%%'' protection. ukbd is detached before context 5 is entered, so it is useless there and that context is irrelevant to ukbd. |
| |
| Routines for non-polling access should already be called with the proper locks, that fact can be asserted in the code. | Routines for non-polling access should already be called with the proper locks, that fact can be asserted in the code. |
| |
| //To do: investigate context 5 more thoroughly// | |
| |