Unknown symbol usb_register_driver
Hi I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study . I have hit upon a problem, when i insert my driver using lsmod, i get an error *Unknown symbol usb_register_driver* *Unknown symbol usb_deregister* I have used these function in my init and exit. I searched through the Linux source code 2.6.35 and 2.6.31. I find that these routines are present but has not been used in even a single driver. My questions 1. Are these some obsolete technique of registering the drivers. If yes then what is the correct method. 2. Are there any code which i have to include before compiling the kernel itself. 3. Are these functions part of any modules which i have to insert using modprobe etc technique -- Regards, Prajosh Premdas
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of Greg KH Sent: Monday, August 29, 2011 12:33 PM To: Prajosh Premdas Cc: kernelnewbies@kernelnewbies.org Subject: Re: Unknown symbol usb_register_driver
On Tue, Aug 30, 2011 at 12:45:11AM +0530, Prajosh Premdas wrote:
Hi
I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study .
The Linux USB subsystem does not allow non-GPL kernel drivers, sorry.
greg k-h
Prajosh, In other words, your efforts to write a non-GPL USB module are stymied by the following in the kernel sources: EXPORT_SYMBOL_GPL(usb_register_driver); EXPORT_SYMBOL_GPL(usb_deregister); So you go through the same rigmarole that everybody else does when they run into this and can't talk their management into GPL'ing the actual source for the module you are writing. You write a little stub module that is GPL that contains two functions that take the same parameters as usb_register_driver() and usb_deregister(). These functions do nothing but call usb_register_driver() and usb_deregister() and return what they return, but you export them with EXPORT_SYMBOL() instead of EXPORT_SYMBOL_GPL(). Your company releases the little stub module under GPL and your private code calls the new functions it exports. You should try to talk your management into GPL'ing the real code and paying you for the time it's going to take you to try to get it accepted into the kernel sources. You can try to argue the benefits to your company of doing so and there are many. It gets reviewed by people who might understand the rest of the system better than you do. If kernel interfaces that your module depends upon change in the future, your module gets updated by the people making the changes; no surprises when you update kernel versions to find the kern_foo() function you've been calling disappears. If a kernel containing your module BUG()s or panic()s, you can submit stack traces without the dreaded "tainted" in them that will cause all of the kernel maintainers to ignore you. But in the world of IP (that's Intellectual Property not Internet Protocol), doing things like "giving code away" is often frowned upon by management particularly when it hides the interface to some ASIC or other piece of hardware that your company wants to keep a secret, so you will very likely not be successful in convincing them to GPL the actual sources and this stupid little hack will allow you to work around this. Jeff Haran
On Mon, Aug 29, 2011 at 01:56:20PM -0700, Jeff Haran wrote:
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of Greg KH Sent: Monday, August 29, 2011 12:33 PM To: Prajosh Premdas Cc: kernelnewbies@kernelnewbies.org Subject: Re: Unknown symbol usb_register_driver
On Tue, Aug 30, 2011 at 12:45:11AM +0530, Prajosh Premdas wrote:
Hi
I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study .
The Linux USB subsystem does not allow non-GPL kernel drivers, sorry.
greg k-h
Prajosh,
In other words, your efforts to write a non-GPL USB module are stymied by the following in the kernel sources:
EXPORT_SYMBOL_GPL(usb_register_driver); EXPORT_SYMBOL_GPL(usb_deregister);
So you go through the same rigmarole that everybody else does when they run into this and can't talk their management into GPL'ing the actual source for the module you are writing.
You write a little stub module that is GPL that contains two functions that take the same parameters as usb_register_driver() and usb_deregister(). These functions do nothing but call usb_register_driver() and usb_deregister() and return what they return, but you export them with EXPORT_SYMBOL() instead of EXPORT_SYMBOL_GPL(). Your company releases the little stub module under GPL and your private code calls the new functions it exports.
If you do that, expect legal action to be taken against you. The "GPL condom" aproach has been tried numerous times by companies with no legal experience with the GPL and every time, it has failed. Samba has numerous public legal cases where this was attempted, if you want some public case history. The Linux attempts to do this have all resulted in the release of the source code, or it no longer being distributed at all. So please don't do that, it only wastes people's time and lawyer money in the end. Unless you want to keep the lawyers in business, then, by all means, go ahead and try this :) good luck, greg k-h
Hi all,
________________________________
I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study .
The Linux USB subsystem does not allow non-GPL kernel drivers, sorry.
like "giving code away" is often frowned upon by management particularly when it hides the interface to some ASIC or other piece of hardware that your company wants to keep a secret,
I know what I have to say is, maybe out of topic but I take advantage of the thread to ask a basic question: The USB interface is very well known today. It is not public but it is very like it was public. There are lots of examples and implementations.
My question is why would one put specific code in a generic communication interface. Does this mean the driver was poorly designed? With a good design the driver will handle the data exchange and the user application will handle the specific (IP hidden) aspects. This split generic_communication_kernel_module / specific_user_application should remove all "NON-GPL" thorns. I am right?
Thanks, Stephan
Hi All Thanks for the reply. I got the initial stuff working. I am not yet clear on what licence this will be released as you guys mentioned i will try to make it on GPL. Stephan, I am trying to make a NIC card of 802.15.4 type. I dont find a point in using ACM class in USB for creating the NIC card as it is defined for Ethernet only. Any suggestions from your end on the same Regrads Prajosh Premdas On Tue, Aug 30, 2011 at 4:02 AM, StephanT <stman937-linewbie@yahoo.com>wrote:
Hi all,
------------------------------
I am using Linux-2.6.31-14 based on Ubuntu karmic. I am developing a proprietary usb driver and was doing my study .
The Linux USB subsystem does not allow non-GPL kernel drivers, sorry.
like "giving code away" is often frowned upon by management particularly when it hides the interface to some ASIC or other piece of hardware that your company wants to keep a secret,
I know what I have to say is, maybe out of topic but I take advantage of the thread to ask a basic question: The USB interface is very well known today. It is not public but it is very like it was public. There are lots of examples and implementations.
My question is why would one put specific code in a generic communication interface. Does this mean the driver was poorly designed? With a good design the driver will handle the data exchange and the user application will handle the specific (IP hidden) aspects. This split generic_communication_kernel_module / specific_user_application should remove all "NON-GPL" thorns. I am right?
Thanks, Stephan
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Prajosh Premdas
participants (4)
-
Greg KH -
Jeff Haran -
Prajosh Premdas -
StephanT