On Tue, Jun 20, 2023 at 7:51 AM Steven Rostedt wrote:
>
> On Mon, 19 Jun 2023 02:43:58 +0200
> Thomas Gleixner wrote:
>
> > Now you might argue that it _is_ a "hotpath" due to the BPF usage, but
> > then even more so as any intermediate wrapper which converts from one
> > data representation to
On Mon, 19 Jun 2023 02:43:58 +0200
Thomas Gleixner wrote:
> Now you might argue that it _is_ a "hotpath" due to the BPF usage, but
> then even more so as any intermediate wrapper which converts from one
> data representation to another data representation is not going to
> increase performance,
On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote:
> Mike!
>
> Sorry for being late on this ...
>
> On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote:
>
> The fact that my suggestions had a 'mod_' namespace prefix does not make
> any of my points moot.
The prefix does not matter.
On Mon, Jun 19, 2023 at 02:43:58AM +0200, Thomas Gleixner wrote:
> Kent!
Hi Thomas :)
> No. I am not.
Ok.
> Whether that's an internal function or not does not make any difference
> at all.
Well, at the risk of this discussion going completely off the rails, I
have to disagree with you there.
Kent!
On Sun, Jun 18 2023 at 19:14, Kent Overstreet wrote:
> On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote:
>
> Thomas, you're confusing an internal interface with external
No. I am not.
Whether that's an internal function or not does not make any difference
at all.
Having a
On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote:
> Mike!
>
> Sorry for being late on this ...
>
> On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote:
> >
> > +void *execmem_data_alloc(size_t size)
> > +{
> > + unsigned long start = execmem_params.modules.data.start;
> > +
Mike!
Sorry for being late on this ...
On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote:
>
> +void *execmem_data_alloc(size_t size)
> +{
> + unsigned long start = execmem_params.modules.data.start;
> + unsigned long end = execmem_params.modules.data.end;
> + pgprot_t pgprot =
On Fri, Jun 16, 2023 at 01:01:08PM -0700, Song Liu wrote:
> On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote:
> >
> > From: "Mike Rapoport (IBM)"
> >
> > Data related to code allocations, such as module data section, need to
> > comply with architecture constraints for its placement and its
>
On Fri, Jun 16, 2023 at 04:55:53PM +, Edgecombe, Rick P wrote:
> On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Data related to code allocations, such as module data section, need
> > to
> > comply with architecture constraints for its
On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> Data related to code allocations, such as module data section, need to
> comply with architecture constraints for its placement and its
> allocation right now was done using execmem_text_alloc().
>
> Create
On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Data related to code allocations, such as module data section, need
> to
> comply with architecture constraints for its placement and its
> allocation right now was done using execmem_text_alloc().
>
>
From: "Mike Rapoport (IBM)"
Data related to code allocations, such as module data section, need to
comply with architecture constraints for its placement and its
allocation right now was done using execmem_text_alloc().
Create a dedicated API for allocating data related to code allocations
and
12 matches
Mail list logo
