I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
Some details about this driver -
1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space N_TI_WL Init manager (UIM) maintaining the Line discipline.
3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.
4. As Alan suggested, If I make it self-contained by pushing number of line disciplines to a slightly larger number, then would it be OK ?
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
That is fine with me, as long as you continue to work on fixing the
issues in the code, and do not object to changing the user/kernel
interface over time to be one that is more sane.
can you explain why you think this is needed and we can not interface
Just from a quick look, I think within a few review cycles this might be
able to get proper upstream inclusion. No idea why bother with staging
in the first place. Lets do this correctly.