Week 21 - planning
First week
First week is almost over. It is almost over since I am still going to do some USB streaming buffer tests tonight :-)This week was scheduled as a RFC and planning for DVB USB changes. DVB USB means those general routines used by almost every digital television USB stick. I think it could be called as a sub-driver, framework, library or even DVB USB core. I still like to call it just DVB USB or DVB USB framework.
I did early start for the first week and sent two RFCs describing planned changes 1-2 weeks earlier. It was not a big surprise there was no many comments. Due to that I think changes I was introducing are not totally wrong :)
Implementing
As there was no much discussion about introduced changes I started implementing those. I copied current DVB USB implementation as a starting point, leaving old implantation still alive as a parallel. It is almost impossible to make such big changes for the existing one as there is about 30 individual DVB USB interface drivers using DVB USB core routines. It is still unknown how to make switch-over for the new implementation. I see two possibilities; 1) move driver by driver to the new 2) move all changes one by one to old implementation.During the development I converted and tested all the time three of my drivers against new routines. Those drivers were au6610, ec168 and af9015. af9015 is one of the most complex DVB USB device drivers and full of hacks. Problems with the af9015 has been my main motivator for most of these DVB USB changes I planned.
Some improved numbers
Changes what I did this week removed many hacks from the af9015. Also those reduced binary size of the af9015 very much.
text data bss dec hex filename
old 14878 13232 40 28150 6df6 dvb-usb-af9015.ko
new 14575 3952 8 18535 4867 dvb-usb-af9015.ko
Space saving is coming from the new way of passing data to the DVB USB framework. Earlier all device data was put inside static struct as now it is passed using driver_info field of the struct usb_device_id.
Size of that configuration structure was always constant, no matter if there was one or 12 devices as current limit is. af9015 driver contains 3 of those big configurations structures. There is some drivers having ~30 similar structs - guess how much space is wasted?
Related links
[RFCv1] DVB-USB improvementshttp://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/47994
[RFCv1] DVB-USB improvements [alternative 2]
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/48572
My DVB USB development tree
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb-usb
No comments:
Post a Comment