drivers/base/bus.c 가 bus subsystem 의 핵심이고,
가장 단순한 형태의 응용이 platform bus 라는 가상 bus 에 대한 구현(drivers/base/platform.c) 입니다.
평범한 응용을 꼽자면 PCI bus 에 대한 구현(drivers/pci/pci-driver.c) 를 들 수 있고,
약간의 기교를 더 부린 응용이 USB bus 에 대한 구현(drivers/usb/core/usb.c) 이라 할 수 있고,
기술로써 예술의 경지를 보여주는 응용이 I2C bus 에 대한 구현(drivers/i2c/i2c-core.c) 이라 생각합니다.
bus_register() 후,
device_register() 혹은 driver_register() 시점에서
bus_type.match() 콜백이 불린다음 bus_type.probe() 콜백이 호출되고,
호출된 bus_type.probe() 콜백에서 i2c_driver.probe() 따위의 드라이버 콜백이 다시 호출되고,
드라이버 콜백에서 각자 고유한 어떤 일이 행해집니다.
grep "\.probe =" * -r
grep "\.probe =" * -r
추가적인 질문이 있는데 하나의 디바이스여도 여러
추가적인 질문이 있는데
하나의 디바이스여도 여러 벤더사의 모듈이 올라가는데
실제 사용될때 어떤 벤더사의 디바이스가 붙으면 해당 디바이스에 맞는 모듈이 동작하는것은 어떠한 구조로 되는건가요?
해당 디바이스가 인식되면 모듈이 계속 돌다가 감지해서 동작 하는건가요..?
그렇다면 실제 모듈이 계속 돌다가 디바이스가 감지되면 매핑이되서 동작 되는 구조인가요?
약간 상세하게 설명해주신다면 감사하겠습니다 ㅜ.ㅜ
drivers/base/bus.c 가 bus
drivers/base/bus.c 가 bus subsystem 의 핵심이고,
가장 단순한 형태의 응용이 platform bus 라는 가상 bus 에 대한 구현(drivers/base/platform.c) 입니다.
평범한 응용을 꼽자면 PCI bus 에 대한 구현(drivers/pci/pci-driver.c) 를 들 수 있고,
약간의 기교를 더 부린 응용이 USB bus 에 대한 구현(drivers/usb/core/usb.c) 이라 할 수 있고,
기술로써 예술의 경지를 보여주는 응용이 I2C bus 에 대한 구현(drivers/i2c/i2c-core.c) 이라 생각합니다.
bus_register() 후,
device_register() 혹은 driver_register() 시점에서
bus_type.match() 콜백이 불린다음 bus_type.probe() 콜백이 호출되고,
호출된 bus_type.probe() 콜백에서 i2c_driver.probe() 따위의 드라이버 콜백이 다시 호출되고,
드라이버 콜백에서 각자 고유한 어떤 일이 행해집니다.
댓글 달기