Messages in this thread | | | Subject | Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols | From | Pavel Roskin <> | Date | Fri, 29 Feb 2008 14:39:38 -0500 |
| |
On Fri, 2008-02-29 at 09:33 -0800, Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Pavel Roskin wrote: > > > > Actually, it's a flawed comparison. The only thing ndiswrapper exports > > to NDIS modules is NDIS API. GPLONLY symbols are only used to implement > > that API in the code that's under GPL. That's the code you can fork, > > change and redistribute. > > .. and it's stuill just a wrapper. > > A fairly thick one, but still...
So it the Linux syscall interface. It's a wrapper around the kernel internals, including GPLONLY symbols. Yet some userspace programs are proprietary.
> More importantly, none of the people arguing against this at all even > reacted to my suggestion for how to fix things *properly* in my original > email. Which just means that you're apparently not interested in actually > fixing this, you're just trying to disagree about some interpretation of > GPLONLY.
I'm actually interested in fixing this, or I would not have sent a patch.
> In other words: the next person who can't even be bothered to tell what > symbols are involved and why they haven't asked whether those symbols > could instead be relaxed, automaticaly will go into my "flamers" filter, > and just stay there. Then you can complain as much as you like, and I'll > never see it.
Well, here's the list
__create_workqueue_key destroy_workqueue flush_workqueue queue_work task_nice usb_alloc_urb usb_buffer_alloc usb_buffer_free usb_clear_halt usb_control_msg usb_deregister usb_free_urb usb_get_current_frame_number usb_get_descriptor usb_get_status usb_ifnum_to_if usb_init_urb usb_kill_urb usb_lock_device_for_reset usb_register_driver usb_reset_configuration usb_reset_device usb_set_interface usb_submit_urb usb_unlink_urb
I already know what USB folks will say. They want proprietary drivers to be in the userspace. I doubt ndiswrapper will ever be ported to the userspace. It's much more likely that some other approach will be used.
-- Regards, Pavel Roskin
| |