On Wed, Jan 18, 2012 at 2:08 AM, Robert Morell wrote:
> The DMA buffer infrastructure (dma-buf) currently exposes its interface
> with EXPORT_SYMBOL_GPL. ?The documentation for EXPORT_SYMBOL_GPL says:
> ? ?"It implies that the function is considered an internal
> ? ?implementation issue, and not r
On Wed, Jan 18, 2012 at 2:08 AM, Robert Morell wrote:
> The DMA buffer infrastructure (dma-buf) currently exposes its interface
> with EXPORT_SYMBOL_GPL. The documentation for EXPORT_SYMBOL_GPL says:
> "It implies that the function is considered an internal
> implementation issue, and not r
> in mind. It would be unfortunate if restricting its use to only
> GPL-licensed modules caused dma-buf adoption to be limited.
You appear confused. I'll say this again is my lawyer advises me that for
the benefit of any future enforcement actions I should remind people
each time it comes up.
Fo
> in mind. It would be unfortunate if restricting its use to only
> GPL-licensed modules caused dma-buf adoption to be limited.
You appear confused. I'll say this again is my lawyer advises me that for
the benefit of any future enforcement actions I should remind people
each time it comes up.
Fo
The DMA buffer infrastructure (dma-buf) currently exposes its interface
with EXPORT_SYMBOL_GPL. The documentation for EXPORT_SYMBOL_GPL says:
"It implies that the function is considered an internal
implementation issue, and not really an interface."
This interface is clearly not just an "i
The DMA buffer infrastructure (dma-buf) currently exposes its interface
with EXPORT_SYMBOL_GPL. The documentation for EXPORT_SYMBOL_GPL says:
"It implies that the function is considered an internal
implementation issue, and not really an interface."
This interface is clearly not just an "i
