Support for this thread has been discontinued by the author. This hotplug implementation has been abandoned in favor for mdev.
The current hotplug chain functions improperly. After looking into the cause of the irritation I have discovered a locking problem in the current system. It seems that the current hotplug system was specified with not more than two block devices (i.e. sda & sda1). IMHO this can be corrected only with a redesign.
The function of the current design is limited to only one hotplug subsystem (usb) ignoring all others (block, ...) and thus requiring locking. To circumvent this, I propose to use the hotplug system as is was implemented: as a state-machine. Following is a time-line documenting my intension.
At t0 (sometime at boot) the modules usbcore and musb_hdrc must be inserted into the kernel. This process does not require inserting nor mounting usbfs. These will 'discover' the hub which will in turn 'discover' any connected (and powered) usb devices. These actions kick-off the above example with chain lead at 2). Here my micro disk.
2) The usb device interface is discovered. This announces itself as the interface 8.6.50: of the mass storage class (8 ), transparent scsi command set subclass (6) with the intrface protocol 'bulk' (50). At this point the appropriate modules usb_storage and sd_mod shall be inserted.
3-5) Here the disk and partitions of the device are 'discovered' and made available. These events are triggered as the nodes are available. Finally, sda2 is mounted.
6) After the node has been successfully mounted, hotplug triggers the corresponding event. Then any required applications may be executed.
I expect this to be minimally intrusive to the current system. I propose triggering the new system when two avm configuration properties are off:
1) aurad
2) ftpd
With these off we are free to implement the above as required.
A proof of concept has been implemented using the following structure containing several files restricting hotplug behavior to the above time line.
The files in the event directory are sourced by the program specified in /proc/sys/kernel/hotplug. The names are indicative to hotplug function: i.e. usb.add will be called when a new usb device has been connected to the system.
The contents of the device directory shall be logically grouped to action and device subclass: i.e. disk.add is sourced as a block device with a node MINOR of 0 becomes available. Last but not least, the lib directory contains files performing specific tasks.
Each of the files in the lib directory contain a single function or a group of logically related functions including a function to eliminate these from the current environment. The naming convention for the contents of a file is <filename>[_<function>[_<sub function>]]. For example, a file led contains the several functions to control the LEDs on the housing. Depending on function these could be named led_on, led_set, led_off, led_clean. The functions on, off and set control the behavior of the LEDs, while clean removes all led_<functions> from the environment. This function will either be called automatically (as in the case of mount) or may be called from the sourcing program.
Being relatively new to freetz I do require more information and a rigorous discussion concerning this subject. Oh, and please feel free to write in German. I will continue to write in English
Please note: the attached archive is for review purposes only. It is highly recommended not to install this package.
The current hotplug chain functions improperly. After looking into the cause of the irritation I have discovered a locking problem in the current system. It seems that the current hotplug system was specified with not more than two block devices (i.e. sda & sda1). IMHO this can be corrected only with a redesign.
The function of the current design is limited to only one hotplug subsystem (usb) ignoring all others (block, ...) and thus requiring locking. To circumvent this, I propose to use the hotplug system as is was implemented: as a state-machine. Following is a time-line documenting my intension.
Code:
t0 --> t1 --> t2 --> t3
load usbcore
(usbfs)
load musb_hdrc
usb block block
add add mount
1-> hub (9.0.0)
2-> mass storage (8.6.xx)
load usb_storage
load sd_mod
3-> sda
exec mknod
exec tune
exec hdparm
exec sg3-tools
4-> sda1
exec mknod
exec blkid
swapon device
5-> sda2 6-> sda2
exec mknod swapon file
exec blkid start apps
load ext2
exec fsck
exec mountAt t0 (sometime at boot) the modules usbcore and musb_hdrc must be inserted into the kernel. This process does not require inserting nor mounting usbfs. These will 'discover' the hub which will in turn 'discover' any connected (and powered) usb devices. These actions kick-off the above example with chain lead at 2). Here my micro disk.
2) The usb device interface is discovered. This announces itself as the interface 8.6.50: of the mass storage class (8 ), transparent scsi command set subclass (6) with the intrface protocol 'bulk' (50). At this point the appropriate modules usb_storage and sd_mod shall be inserted.
3-5) Here the disk and partitions of the device are 'discovered' and made available. These events are triggered as the nodes are available. Finally, sda2 is mounted.
6) After the node has been successfully mounted, hotplug triggers the corresponding event. Then any required applications may be executed.
I expect this to be minimally intrusive to the current system. I propose triggering the new system when two avm configuration properties are off:
1) aurad
2) ftpd
With these off we are free to implement the above as required.
A proof of concept has been implemented using the following structure containing several files restricting hotplug behavior to the above time line.
Code:
fritzbox@new-york:~/freetz/hotplug/src$ ls -lR | egrep '^(d|\.|-).*'
.:
drwxr-x--- 2 fritzbox fritzbox 176 2008-04-13 19:56 device
drwxr-x--- 2 fritzbox fritzbox 232 2008-04-13 20:03 event
-rwxr-x--- 1 fritzbox fritzbox 457 2008-04-12 10:31 hotplug
drwxr-x--- 2 fritzbox fritzbox 184 2008-04-13 20:03 lib
./device:
-rw-r----- 1 fritzbox fritzbox 2200 2008-04-11 17:30 avmusbwlan.add
-rw-r----- 1 fritzbox fritzbox 297 2008-04-11 17:30 avmusbwlan.remove
-rw-r----- 1 fritzbox fritzbox 217 2008-04-09 12:56 disk.add
-rw-r----- 1 fritzbox fritzbox 570 2008-04-12 14:29 partition.add
./event:
-rw-r----- 1 fritzbox fritzbox 426 2008-04-13 19:56 block.add
-rw-r----- 1 fritzbox fritzbox 579 2008-04-13 11:45 block.mount
-rw-r----- 1 fritzbox fritzbox 135 2008-04-13 08:53 block.remove
-rw-r----- 1 fritzbox fritzbox 641 2008-04-13 11:42 block.umount
-rw-r----- 1 fritzbox fritzbox 300 2008-04-13 18:00 usb.add
-rw-r----- 1 fritzbox fritzbox 380 2008-04-12 10:39 usb_device.add
./lib:
-rw-r----- 1 fritzbox fritzbox 129 2008-04-11 17:27 ar7value
-rwxr-x--- 1 fritzbox fritzbox 9992 2008-04-11 09:07 avmusbwlanstart
-rw-r----- 1 fritzbox fritzbox 278 2008-04-11 17:29 led
-rw-r----- 1 fritzbox fritzbox 292 2008-04-11 17:28 loadmodules
-rw-r----- 1 fritzbox fritzbox 2407 2008-04-13 20:03 mountThe files in the event directory are sourced by the program specified in /proc/sys/kernel/hotplug. The names are indicative to hotplug function: i.e. usb.add will be called when a new usb device has been connected to the system.
The contents of the device directory shall be logically grouped to action and device subclass: i.e. disk.add is sourced as a block device with a node MINOR of 0 becomes available. Last but not least, the lib directory contains files performing specific tasks.
Each of the files in the lib directory contain a single function or a group of logically related functions including a function to eliminate these from the current environment. The naming convention for the contents of a file is <filename>[_<function>[_<sub function>]]. For example, a file led contains the several functions to control the LEDs on the housing. Depending on function these could be named led_on, led_set, led_off, led_clean. The functions on, off and set control the behavior of the LEDs, while clean removes all led_<functions> from the environment. This function will either be called automatically (as in the case of mount) or may be called from the sourcing program.
Being relatively new to freetz I do require more information and a rigorous discussion concerning this subject. Oh, and please feel free to write in German. I will continue to write in English
Please note: the attached archive is for review purposes only. It is highly recommended not to install this package.
Zuletzt bearbeitet:
