fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<kerneltoast>
it's a toughie
<fche>
so how does the kernel manage to service reads without comparing i_size ?
<kerneltoast>
by checking for EOF maybe
<fche>
yeah but how does it konw to signal EOF
<kerneltoast>
hmm that'd require a buncha vfs digging
<kerneltoast>
and i'm not sure the answer will help us
<fche>
yeah just in case some other hack suggests itself
hpt has joined #systemtap
orivej has joined #systemtap
<fche>
kerneltoast, can we call kernel_read() rather than kernel_read_file() ?
<fche>
we don't need all of its kernel_security* goo checking or anything
<fche>
though it may be even simpler if we ditch the buffer alloc/free
<fche>
and just use a little wee 30-byte thing on the stack
<kerneltoast>
you fine with that?
<kerneltoast>
i love stack allocs but i remember stap is paranoid about em
<kerneltoast>
we could be ballsy and use 19 bytes
<fche>
let's round it up a wee but yeah
<kerneltoast>
32 bytes?
<fche>
sure what the heck.
<kerneltoast>
almighty power of 2
<fche>
phear me
<fche>
a little bit
<kerneltoast>
fche, you wanna trust that kernel_read() will terminate our buffer?
<kerneltoast>
or i can zero it
<kerneltoast>
or i can parse the returned len from kernel_read() and set the last byte to 0
<fche>
yes, that
<fche>
kstrtoul doesn't take the length, slacker
<kerneltoast>
yea but how ballsy do we wanna be
<kerneltoast>
this is very importante performance 0ptimizat0nz
<kerneltoast>
i guess i'll just zero on the stack
<fche>
suggest buf[len] = '\0'
<fche>
yea
irker879 has joined #systemtap
<irker879>
systemtap: sultan systemtap.git:master * release-4.4-135-g104cf26b4 / buildrun.cxx runtime/linux/autoconf-kernel_read-new-args.c runtime/linux/autoconf-kernel_read_file_from_path-offset.c runtime/transport/symbols.c: Always get section info via sysfs using kernel_read()