On Fri, Jul 15, 2016 at 12:56 AM, Sasha Goldshtein <goldshtn@...> wrote:
> On Fri, Jul 15, 2016 at 3:59 AM Alexei Starovoitov
> <alexei.starovoitov@...> wrote:
>>
>> On Wed, Jul 13, 2016 at 4:17 PM, Kyle Laracey via iovisor-dev
>> <iovisor-dev@...> wrote:
>> >
>> > An additional issue brought up on the call (I apologize for forgetting
>> > by
>> > whom) was that any comparisons on long strings would bloat the program,
>> > perhaps beyond the maximum allowed program size. Would the solution to
>> > this
>> > be to have something like another BPF helper function in the kernel?
>>
>> the idea we discussed is to introduce string map similar to stackmap
>> where different strings are referenced by id. The helper would be able
>> to push user or kernel strings into this map.
>> That should solve https://github.com/iovisor/bcc/issues/607
>> What is your use case that needs strings?
>> To come up with good kernel design we need to
>> categorize all use cases that need strings.
>
>
> Both the trace and argdist tools collect strings from tracepoints,
> uprobes/kprobes, and USDT tracepoints. These strings are displayed to the
> user (trace) [1] or used as keys for histograms and event frequency counters
> (argdist) [2]. The length of the string is usually not known in advance, so
> something like strcpy would be very useful.
>
> The proposed string map solution would work as long as the kernel helper
> would be able to support two modes of operation: read string until null
> terminator, and read N characters.

exactly. was thinking about:
u32 id = bpf_get_unsafe_string(map, unsafe_ptr, len_or_zero)
that returns negative error or 32-bit string id.
either it copies 'len' bytes or the whole string.