Skip to main content.
Navigation:
DENX
>
Training2
>
LddDriverModelIntro
Translations:
Edit
|
Attach
|
Raw
|
Ref-By
|
Printable
|
More
Training2
Sections of this site:
DENX Home
|
DULG
|
ELDK-5
|
Know
|
Training
|
U-Boot
|
U-Bootdoc
Topics
Training2 Home
Changes
Index
Search
Go
List of pages in Training2
Search
%SECTION0{name=LddDriverModelIntro}% Driver model and sysfs * motivation (state pre 2.5): * no uniform, comprehensive model, only bus specific lists of devices * =procfs= was getting messy (large files, not hierarchy) * more and more hotpluggable devices * generic power and shutdown management impossible * solution: _driver model_ * introduced in 2.5, evolved a lot! * uniform model for representing busses, devices and drivers as a hierarchy * sysfs * often confused with driver model * special file system that exports hierarchical view of all the devices in the system * driver model can exist without sysfs, but sysfs not without driver model * Characteristics: * discoverable (device classes) * how interconnected? * cleaner: one value per sysfs file * handles reference counting * generic hotplug support * The driver model is _very_ complex, but fortunately the kernel does most work for us *example* <verbatim> $ tree -L 1 /sys/ /sys/ |-- block |-- bus |-- class |-- devices |-- firmware |-- fs |-- kernel |-- module `-- power </verbatim> explore with =tree(1)=
5.5. The Linux driver model
1. Denx Training Topics
5.5.2. How does it all fit together?
Prev
Home
Next