DXR3
From APIDesign
| (4 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
However two weeks ago, my harddrive crashed and I had to upgrade the internals of my computer. While recovering from the failure, I upgraded to [[Kubuntu]] 12.04. However, then I noticed that the '''em8300''' driver (for [[DXR3]] card) no longer compiles (I guess this is another sign that the amount of [[DXR3]] users is decreasing). After considering all alternatives I decided to do a bit of kernel hacking and update the driver code myself. | However two weeks ago, my harddrive crashed and I had to upgrade the internals of my computer. While recovering from the failure, I upgraded to [[Kubuntu]] 12.04. However, then I noticed that the '''em8300''' driver (for [[DXR3]] card) no longer compiles (I guess this is another sign that the amount of [[DXR3]] users is decreasing). After considering all alternatives I decided to do a bit of kernel hacking and update the driver code myself. | ||
| - | I've downloaded the latest version I could find (0.18.0) and tried to make it compile on [[Kubuntu]] 12.04. [[Linux]] kernel is famous for ignoring [[BackwardCompatibility]] and rather requiring | + | I've downloaded the latest version I could find (0.18.0) and tried to make it compile on [[Kubuntu]] 12.04. [[Linux]] kernel is famous for ignoring [[BackwardCompatibility]] and rather requiring every driver maintainer to rewrite to new [[API]]s. This sort of works, while there is enough people really interested in particular drivers. In fact upgrading was not that hard. I would call it ''google based upgrade'' (which seems to be nice example of [[cluelessness]]): |
# type '''make''' | # type '''make''' | ||
# wait for the error message | # wait for the error message | ||
# put it into your favourite search engine | # put it into your favourite search engine | ||
| - | # among first three references finds the one from kernel.org mailing list to get a clue of what to do | + | # among first three references finds the one from kernel.org mailing list to [[cluelessness|get a clue]] of what to do |
| - | The ridiculous observation I made is the common enthusiastic feeling the people on the mailing list have that they broke somebody else's code! The announcement usually does not concentrate on the reasons and suggestions how to upgrade. Rather most of the messages explain why it is so cool that the guys could rename some function or field in a structure or change the number of arguments! | + | The ridiculous observation I made is the common enthusiastic feeling the people on the mailing list have that they broke somebody else's code! The announcement usually does not concentrate on the reasons and suggestions how to upgrade. Rather most of the messages explain why it is so cool that the guys could rename some function or field in a structure or change the number of arguments! Few sample diffs follows: |
| - | It must be a fun to be [[Linux]] kernel developer. Too bad I don't share the same sense of humor and I rather keep the old [[API]] elements around, delegating to the new alternatives. But it's just me. Or wait, isn't that | + | <source lang="diff"> |
| + | - init_MUTEX(&em8300_alsa->lock); | ||
| + | + sema_init(&em8300_alsa->lock, 1); | ||
| + | |||
| + | - em->eeprom = i2c_new_probed_device(&em->i2c_ops_2, &i2c_info, eeprom_addr); | ||
| + | + em->eeprom = i2c_new_probed_device(&em->i2c_ops_2, &i2c_info, eeprom_addr, NULL); | ||
| + | |||
| + | - .ioctl = em8300_dsp_ioctl, | ||
| + | + .unlocked_ioctl = em8300_dsp_ioctl, | ||
| + | </source> | ||
| + | |||
| + | It must be a fun to be [[Linux]] kernel developer. Too bad I don't share the same sense of humor. I don't really get what is so cool on renaming a field called '''.ioclt''' to '''.unlocked_ioctl''' and claim that this is a huge step forward for the [[Linux]] Kernel! I rather keep the old [[API]] elements around, delegating to the new alternatives. But it's just me. Or wait, isn't that [[Java]]? [[C]] does not have overloaded functions - so it would not be easy to keep the old '''i2c_new_probed_device''' function with less parameters around!? | ||
Anyway I am glad I made the ''em8300'' driver work on [[Linux]] kernel 3.2.0. | Anyway I am glad I made the ''em8300'' driver work on [[Linux]] kernel 3.2.0. | ||
The patch is available in [https://sourceforge.net/tracker/?func=detail&aid=3532929&group_id=5165&atid=105165 dxr3.sf.net bugtracking system]. If you find it useful, please let me know. I'll be glad to hear that my [[Linux]]/[[C]] coding flashback was useful for more people than just me. | The patch is available in [https://sourceforge.net/tracker/?func=detail&aid=3532929&group_id=5165&atid=105165 dxr3.sf.net bugtracking system]. If you find it useful, please let me know. I'll be glad to hear that my [[Linux]]/[[C]] coding flashback was useful for more people than just me. | ||
| - | + | [[Category:OpenSourceContribution]] | |
Current revision
DXR3 is a hardware MPEG-2 decoder card. I may be one of the last users of DXR3 on the planet, but I still find it useful for sending S-Video and Dolby Digital signals to my home theatre system attached to my computer.
However two weeks ago, my harddrive crashed and I had to upgrade the internals of my computer. While recovering from the failure, I upgraded to Kubuntu 12.04. However, then I noticed that the em8300 driver (for DXR3 card) no longer compiles (I guess this is another sign that the amount of DXR3 users is decreasing). After considering all alternatives I decided to do a bit of kernel hacking and update the driver code myself.
I've downloaded the latest version I could find (0.18.0) and tried to make it compile on Kubuntu 12.04. Linux kernel is famous for ignoring BackwardCompatibility and rather requiring every driver maintainer to rewrite to new APIs. This sort of works, while there is enough people really interested in particular drivers. In fact upgrading was not that hard. I would call it google based upgrade (which seems to be nice example of cluelessness):
- type make
- wait for the error message
- put it into your favourite search engine
- among first three references finds the one from kernel.org mailing list to get a clue of what to do
The ridiculous observation I made is the common enthusiastic feeling the people on the mailing list have that they broke somebody else's code! The announcement usually does not concentrate on the reasons and suggestions how to upgrade. Rather most of the messages explain why it is so cool that the guys could rename some function or field in a structure or change the number of arguments! Few sample diffs follows:
- init_MUTEX(&em8300_alsa->lock); + sema_init(&em8300_alsa->lock, 1); - em->eeprom = i2c_new_probed_device(&em->i2c_ops_2, &i2c_info, eeprom_addr); + em->eeprom = i2c_new_probed_device(&em->i2c_ops_2, &i2c_info, eeprom_addr, NULL); - .ioctl = em8300_dsp_ioctl, + .unlocked_ioctl = em8300_dsp_ioctl,
It must be a fun to be Linux kernel developer. Too bad I don't share the same sense of humor. I don't really get what is so cool on renaming a field called .ioclt to .unlocked_ioctl and claim that this is a huge step forward for the Linux Kernel! I rather keep the old API elements around, delegating to the new alternatives. But it's just me. Or wait, isn't that Java? C does not have overloaded functions - so it would not be easy to keep the old i2c_new_probed_device function with less parameters around!?
Anyway I am glad I made the em8300 driver work on Linux kernel 3.2.0. The patch is available in dxr3.sf.net bugtracking system. If you find it useful, please let me know. I'll be glad to hear that my Linux/C coding flashback was useful for more people than just me.
Follow
