![]() | |||||||||||||
Messages in this thread |
Brian F. G. Bidulock wrote: > Stephen, > > On Tue, 13 Jun 2006, Stephen Hemminger wrote: > > >>>@@ -2176,3 +2279,13 @@ EXPORT_SYMBOL(sock_wake_async); >>> EXPORT_SYMBOL(sockfd_lookup); >>> EXPORT_SYMBOL(kernel_sendmsg); >>> EXPORT_SYMBOL(kernel_recvmsg); >>>+EXPORT_SYMBOL(kernel_bind); >>>+EXPORT_SYMBOL(kernel_listen); >>>+EXPORT_SYMBOL(kernel_accept); >>>+EXPORT_SYMBOL(kernel_connect); >>>+EXPORT_SYMBOL(kernel_getsockname); >>>+EXPORT_SYMBOL(kernel_getpeername); >>>+EXPORT_SYMBOL(kernel_getsockopt); >>>+EXPORT_SYMBOL(kernel_setsockopt); >>>+EXPORT_SYMBOL(kernel_sendpage); >>>+EXPORT_SYMBOL(kernel_ioctl); >> >>Don't we want to restrict this to GPL code with EXPORT_SYMBOL_GPL? > > > There are direct derivatives of the BSD/POSIX system call > interface. The protocol function pointers within the socket > structure are not GPL only. Why make this wrappered access to > them GPL only? It will only encourange the reverse of what they > were intended to do: be used instead of the protocol function > pointers within the socket structure, that currently carry no > such restriction. This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-06-13 23:15 [from the cache] ©2003-2008 | |||||||||||||