Messages in this thread | | | Date | Fri, 4 Apr 2008 20:06:10 +0300 | From | Eduard - Gabriel Munteanu <> | Subject | Re: [PATCH] relay: add buffer-only functionality, allowing for early kernel tracing |
| |
On Fri, 4 Apr 2008 12:40:22 -0400 Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> Then I guess we would depend on page_alloc_init(). It's not that bad, > but I guess the question is : do we prefer to let users specify the > buffer size to reserve for tracing on the kernel command line (that > would require __get_free_pages()) or do we compile-in a static buffer > size, which can be specified in the kernel configuration. I think > providing both could be an option : flexibility _and_ *very* early > tracing.
I wasn't referring to the kernel's users specifying the buffer on the command line. For example, LTTng code (I'm not familiar with it) could allocate a buffer, by itself or using a helper function, and pass it to relay_early_open(). Of course, it could read the command line and call that helper function, passing the size required by the user as an argument.
Basically, I'm saying that having relay code manage a large buffer, allocating memory from it for each of its callers, could be very complex. It would be easier and less complex to let each tracing subsystem allocate memory on its own, either through a static buffer or with __get_free_pages().
> So making this relay interface flexible enough to receive a buffer > either reserved by __get_free_pages() or a static buffer seems like a > good compromise. It would also have to receive the buffer size from > the caller.
Yes, it shouldn't matter to the relay interface whether the buffer was statically or dynamically allocated. All it needs to know is where it starts and how long it is.
BTW, I'll resubmit a modified patch soon, as suggested by Randy Dunlap.
Eduard
| |