Para poder explicar el trabajo que esta desarrollando Mjmartin, es necesario comprender (a nivel básico) cómo funciona “el USB 2.0”. Para la gran mayoría de los mortales,el USB es un conector donde enganchamos el ratón, el pendrive o la impresora, de manera casi inconsciente, pero tras ese pequeño gesto se esconde un interesante mecanismo de software bastante “sencillo” de entender.
A la izquierda se puede ver el diagrama USB para Windows XP (y ReactOS) donde se indican las relaciones de los drivers que entran en juego cuando conectamos nuestro teclado(por ejemplo) a dicho conector.
¿Usbuhci,usbohci y usbehci?
En el primer nivel se diferencian 3 Drivers Minipuerto: usbuhci, usbohci y usbehci. Estos drivers son realmente ficheros que podeis encontrar con los nombres usbuhci.sys,usbohci.sys y usbehci.sys en Windows. Cuando conectamos un dispositivo a nuestro ordenador, lo primero que ocurre es que se carga uno de estos drivers.
El usbehci.sys es cargado cuando conectamos a nuestro ordenador un dispositivo USB 2.0, mientras que si conectamos un dispositivo 1.1 el driver responsable es el usbohci.sys.
Actualmente ReactOS cuenta con un driver usbohci.sys(USB 1.1),el cual no funciona correctamente, y es por ello que los dispositivos 1.1 no son detectados(salvo honrosas excepciones).
Estos minidrivers son independientes entre sí.Como curiosidad,podríamos tener un SO capaz de reconocer dispositivos USB 2.0 y no dispositivos USB1.1, con solo borrar el usbohci.sys.(Mejor que no lo intentéis).
Resumiendo: nosotros conectamos nuestro pendrive,el SO detecta si es USB 1.1 o 2.0, si es USB 1.1 carga el usbohci.sys, si es USB 2.0 carga el usbehci.sys. ¿Y ahora que?
El USBport.sys
Una vez que se ha cargado el Driver Minipuerto correcto, éste carga el Driver Controlador llamado USBPort. Otro “fichero” que podéis encontrar en Windows.
El Usbport.sys es el encargado de realizar las tareas comunes, mientras que los Driver Minipuertos llevan a cabo las tareas específicas de USB 1.1 o USB 2.0. Esto evita la duplicación de código,y ayuda a una buena modularidad, pudiendo crear en un futuro USB 4.0, el USB 5.0 o el USB X.X simplemente añadiendo nuevos drivers Minipuerto.
El USBhub.sys
Pero en un PC no tenemos un único puerto USB, sino varios.Algunos estarán vacíos,en otros tendremos conectados varios dispositivos USB(la impresora,el pendrive, el ratón…), incluso es posible que en algún puerto USB pongamos un HUB para ampliar el número de puertos USB.¿Quién gestiona todo este lío?El HUB(BUS)driver USBHUB.sys.
Un funcionamiento incorrecto del USBhub.sys haría que el puerto del ratón recibiera un fichero que debería estar copiándose en el pendrive, por ejemplo.
¿Y ahora qué?
Como se puede ver en el diagrama existen dos posibilidades. La primera es que se llame a un DRIVER del DISPOSITIVO CLIENTE USB. Y la otra es que se carge el usbccgp.sys, que cargará varios DRIVER de DISPOSITIVOS CLIENTE USB.
La primera situación, llamar a un único DRIVER, se produce cuando conectamos un dispositivo no-compuesto a nuestro Puerto USB. Si el dispositivo es compuesto entonces se carga primero el usbccgp.sys y éste carga varios DRIVER de DISPOSITIVOS CLIENTE USB.
Pero alto…¿Compuesto?¿No compuesto?..
¿No-compuesto?¿Compuesto?
Algo interesante en este Diagrama es la modularidad que también se refleja en los Drivers de Dispositivo Cliente USB.
Para la especificación USB todo puede ser subdividido en “módulos”(o DRIVERS de DISPOSITIVO CLIENTE USB). Por ejemplo: Un driver HID(que se encarga de manejar los dispositivos de entrada de datos), Un driver para Power Management ( que se encarga de gestionar la alimentación a los dispositivos, gracias a ello los discos duros externos de 2 pulgadas no necesitan alimentación extra), un driver para Mass Storage (que se encarga de gestionar la transferencia de ficheros),entre otros.
Así pues una cámara de fotos necesita cargar dos módulos(básicamente):el DRIVER DE DISPOSITIVO CLIENTE para Storage, y el DRIVER DE DISPOSITIVO CLIENTE de Power Management. Por lo tanto es un dispositivo USB COMPUESTO.
Un ratón USB de bola solo necesita cargar un módulo: el DRIVER de DISPOSITIVO CLIENTE HID(Dispositivo de Interfaz Humana) para mandar los datos del movimiento de la bola al PC. Por lo tanto es un dispositivo USB NO-COMPUESTO.
Si el ratón USB es de cable pero Láser,entonces necesita tanto el HID como el Power Management.Otro ejemplo de USB COMPUESTO.
Resumiendo: Si el dispositivo es COMPUESTO entonces primero se carga el DRIVER GENÉRICO PATERNO(el usbccgp.sys) que a su vez carga los Drivers de dispositivo cliente necesarios. Si el dispositivo es NO-COMPUESTO, entonces directamente se carga el Driver de dispositivo cliente necesario.
El trabajo de mjmartin
Ahora ya es más facil comprender el trabajo de mjmartin. Actualmente se está dedicando a crear el Driver MiniPuerto USBehci.sys, necesario para realizar funciones específicas de USB 2.0.
Es el primer paso para poder tener soporte USB 2.0,ya que en el trunk contamos con el USBport.sys y el USBhub.sys (aunque a nivel muy primitivo),necesario para nuestro actual (y escaso) soporte USB 1.1.
Para comprobar el grado de compatibilidad del usbehci.sys creado por mjmartin, nuestro desarrollador sustituye en Windows XP el usbehci original por la versión en desarrollo.De esta manera puede detectar si su comportamiento es similar o si existen bugs a resolver. La implementación es muy básica y actualmente produce algunos cuelgues en la máquina donde se está testeando, aunque ha sido capaz de reconocer varios dispositivos USB 2.0.
Una vez que termine de desarrollar el Driver Minipuerto,nos ha comentado que subirá un nivel para mejorar la compatibilidad del actual USBport.sys. De esta manera no solo mejorará la compatibilidad global del USB 2.0, sino que también la del USB 1.1.
Tras ello, pasará a estudiar el código del actual Driver MiniPuerto usbohci.sys, si los fixes en el USBport.sys no son suficientes para hacer ReactOS compatible con los dispositivos 1.1.
Y esto es todo por ahora,en cuanto hayan más novedades sobre el estado actual del USB, las iremos comentando ;)
Tal y como lo explicas, ¡hasta parece sencillo y todo! ;-)
ResponderEliminarLo dicho: cuanto más se avance en el desarrollo, más programadores se apuntarán a este proyecto y más objetivos se alcanzarán con mayor rapidez.
Gracias por el blog.
Jejej gracias ;)
ResponderEliminarRealmente la estructura es sencilla, pero la implementación es un autentico latazo.Hay que implementar todos esos drivers, y eso requiere su tiempo. Espero que la sencillez en la explicación no oculte la complejidad del código a implementar.
Y respecto a que parece sencillo, para mi es un gran elogio, pues realmente intento que cada post pueda ser seguido hasta por mi abuela.Ella es mi revisora, si ella no lo entiende,entonces hay que reescribirlo ;). Muchas veces el problema de las explicaciones que te puedes encontrar por Internet, es que se regodean en sus "palabros" técnicos,o le dan tantas vueltas que al final pierdes el contacto con la realidad.Todo al final son ficheros y los ficheros son visibles.Eso hace más tangible y real las explicaciones,o eso espero. :)
Otras veces el problema se reduce a que la información está totalmente desordenada, y simplemente ordenandolo paso a paso, hace mas comprensible el mismo texto. Si en este Post hubiera comenzado a saltar de lado a lado, sería totalmente infumable y te habrías perdido 10 veces.
Básicamente intento evitar todos los fallos que he visto en muchos de los profesores de Universidad ;)..este Post va por ellos :p
Pues si, se dice facil pero no lo es tanto. Creo que en este caso lo mejor sera ir por partes y empezar desde el principio ja, me refiero a dar prioridad a las memorias y dispositivos de almacenamiento basicos, los que no requieren de alimentacion para cargarse y ni que dividan al puerto en varios como los hub, con eso creo q se avanza bastante bueno pues nos seguimos leyendo.
ResponderEliminar[...] alguien no recuerda el esquema USB, en esta entrada podeís encontrar la base mínima para comprenderlo.Repaso el esquema mientras hablo con él y me [...]
ResponderEliminar