Re: [PATCH 05/14] KDB: add more exports for supporting KDB modules

[ebiederm@xmission.com (Eric W. Biederman)]

Mike Travis <travis@sgi.com> writes:

> Let me see if I can understand the concept better.  By denying
> an external hardware vendor the use of KDB to support a significant
> piece of proprietary hardware on Linux, I furthering the interests
> of Linux and the community how?

By ignoring interests of someone who does not coopearte with the
community we encourage people to cooperate with the community.

> Looking back at the KDB sources originally posted on oss.sgi.com I
> did not see any restrictions on the use of KDB.  How/why was that
> restriction granted and by whom?  Was SGI, the original copyright
> owner of KDB, asked or even informed of that decision?  I'm not
> trying to be a lawyer here, but someone decided (perhaps wrongly)
> that KDB should only be used by GPL modules.

The symbols quoted below are have absolutely nothing to do with KDB
ever.  They are pieces of code that you should only use in very
exceptional circumpstances, or you risk breaking the kernel in strange
and mysterious ways.

Beyond that there are modules with GPL compatible licenses.  That is the
only kind of module that the kernel license allows.

> I'm not married to this matter by any means and I will change them all
> if that's what's needed for acceptance.  But I do think that placing
> unnecessary roadblocks in the path of developing more capabilities
> for the Linux system, is causing a disservice to the the users of
> Linux and the overall Linux community.

A capability that no one else can use, and that generates support
requests that can not be supported is not developing more capabilities
for the Linux system.  It is denying those of us who ask for repayment
in code, our compensation.  It is theft.

Eric

>>> --- linux.orig/kernel/signal.c
>>> +++ linux/kernel/signal.c
>>> @@ -1419,7 +1419,7 @@ out_unlock:
>>>   	rcu_read_unlock();
>>>   	return ret;
>>>   }
>>> -EXPORT_SYMBOL_GPL(kill_pid_info_as_cred);
>>> +EXPORT_SYMBOL(kill_pid_info_as_cred);
>>>
>>>   /*
>>>    * kill_something_info() interprets pid in interesting ways just like kill(2).
>>> @@ -2491,7 +2491,7 @@ out:
>>>   }
>>>
>>>   EXPORT_SYMBOL(recalc_sigpending);
>>> -EXPORT_SYMBOL_GPL(dequeue_signal);
>>> +EXPORT_SYMBOL(dequeue_signal);
>>>   EXPORT_SYMBOL(flush_signals);
>>>   EXPORT_SYMBOL(force_sig);
>>>   EXPORT_SYMBOL(send_sig);
>>> @@ -3661,4 +3661,5 @@ kdb_send_sig_info(struct task_struct *t,
>>>   	else
>>>   		kdb_printf("Signal %d is sent to process %d.\n", sig, t->pid);
>>>   }
>>> +EXPORT_SYMBOL(kdb_send_sig_info);
>>>   #endif	/* CONFIG_KGDB_KDB */