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().
>
>
11 matches
Mail list logo
