search for: _gpl

...n previously exported regardless of that document. > > Can you point me to any specific example where this would be the case > for the core kernel symbols please? The most recent example that comes to mind was the thrash around __kernel_fpu_{begin,end} [1]. I referenced that when debating _GPL symbol policy with Jérôme [2]. [1]: https://lore.kernel.org/lkml/20190522100959.GA15390 at kroah.com/ [2]: https://lore.kernel.org/lkml/CAPcyv4gb+r==riKFXkVZ7gGdnKe62yBmZ7xOa4uBBByhnK9Tzg at mail.gmail.com/

...n, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote: > > > I asked for this simply because it was not exported historically. In > > > general I want to establish explicit export-type criteria so the > > > community can spend less time debating when to use EXPORT_SYMBOL_GPL > > > [1]. > > > > > > The thought in this instance is that it is not historically exported > > > to modules and it is safer from a maintenance perspective to start > > > with GPL-only for new symbols in case we don't want to maintain that > >...

...-0700, Dan Williams wrote: > > > > > I asked for this simply because it was not exported historically. In > > > > > general I want to establish explicit export-type criteria so the > > > > > community can spend less time debating when to use EXPORT_SYMBOL_GPL > > > > > [1]. > > > > > > > > > > The thought in this instance is that it is not historically exported > > > > > to modules and it is safer from a maintenance perspective to start > > > > > with GPL-only for new symbols in...

...at 11:24:48AM -0700, Dan Williams wrote: > > > > I asked for this simply because it was not exported historically. In > > > > general I want to establish explicit export-type criteria so the > > > > community can spend less time debating when to use EXPORT_SYMBOL_GPL > > > > [1]. > > > > > > > > The thought in this instance is that it is not historically exported > > > > to modules and it is safer from a maintenance perspective to start > > > > with GPL-only for new symbols in case we don't want to...

...; diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + return -ENODEV; > + > + return dmabu...

...; diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + return -ENODEV; > + > + return dmabu...

On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote: > I asked for this simply because it was not exported historically. In > general I want to establish explicit export-type criteria so the > community can spend less time debating when to use EXPORT_SYMBOL_GPL > [1]. > > The thought in this instance is that it is not historically exported > to modules and it is safer from a maintenance perspective to start > with GPL-only for new symbols in case we don't want to maintain that > interface long-term for out-of-tree modules. > &gt...

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

Hi folks, After some time away from it, and a big rebase as a consequence, here is the updated version of paravirt_ops for x86_64, heading to inclusion. Your criticism is of course, very welcome. Have fun -- arch/x86_64/Kconfig | 11 arch/x86_64/ia32/syscall32.c | 2 arch/x86_64/kernel/Makefile | 1 arch/x86_64/kernel/apic.c | 2

....load_tls = nopara_load_tls, + .write_ldt_entry = nopara_write_ldt_entry, + .write_gdt_entry = nopara_write_gdt_entry, + .write_idt_entry = nopara_write_idt_entry, + + .set_iopl_mask = nopara_set_iopl_mask, + .irq_enable_sysexit = nopara_irq_enable_sysexit, + .iret = nopara_iret, +}; +EXPORT_SYMBOL_GPL(paravirt_ops); =================================================================== --- /dev/null +++ b/include/asm-i386/paravirt.h @@ -0,0 +1,219 @@ +#ifndef __ASM_PARAVIRT_H +#define __ASM_PARAVIRT_H +/* Various instructions on x86 need to be replaced for + * para-virtualization: those hooks are d...

....load_tls = nopara_load_tls, + .write_ldt_entry = nopara_write_ldt_entry, + .write_gdt_entry = nopara_write_gdt_entry, + .write_idt_entry = nopara_write_idt_entry, + + .set_iopl_mask = nopara_set_iopl_mask, + .irq_enable_sysexit = nopara_irq_enable_sysexit, + .iret = nopara_iret, +}; +EXPORT_SYMBOL_GPL(paravirt_ops); =================================================================== --- /dev/null +++ b/include/asm-i386/paravirt.h @@ -0,0 +1,219 @@ +#ifndef __ASM_PARAVIRT_H +#define __ASM_PARAVIRT_H +/* Various instructions on x86 need to be replaced for + * para-virtualization: those hooks are d...