On Fri, 4 Apr 2008 12:40:22 -0400
Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
 
quoted text
> 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().

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/