linux-kernel - Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1204313978.2316.8.camel@dv>
Date:	Fri, 29 Feb 2008 14:39:38 -0500
From:	Pavel Roskin <proski@....org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Zan Lynx <zlynx@....org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jon Masters <jcm@...masters.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only
	symbols

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/