For now, we support 2 types of arguments to print, which is our mapping for bpf_printk: normal strings and python f-strings.
However, we do not support all the expressions that Python supports in their f-strings. All the arguments to the f-strings used in print inside a bpf chunk have to be named variables.
So,
print("Hello") is allowedprint(f"My name is {name}") is allowedprint(f"1 + 1 is {1 + 1}") is NOT allowed- Even
print(1 + 1) is NOT allowed
I came across this while working on #40, where I am allocating a scratch space for bpf helper arguments that are passed as constants or binary operations, as they need to be stored somewhere and then passed.
The mechanism I use there is not directly compatible with print due to the way we handle f-strings in print (f-strings can only occur as an arg to print, so we don't bother separating it's handling logic out to expr_pass).
Of course, there are ways to overcome these, that is the reason I am marking this issue as a wishlist item. But we must do this some time in the future for the sake of a more pythonic syntax.
For now, we support 2 types of arguments to
print, which is our mapping forbpf_printk: normal strings and python f-strings.However, we do not support all the expressions that Python supports in their f-strings. All the arguments to the f-strings used in
printinside abpfchunk have to be named variables.So,
print("Hello")is allowedprint(f"My name is {name}")is allowedprint(f"1 + 1 is {1 + 1}")is NOT allowedprint(1 + 1)is NOT allowedI came across this while working on #40, where I am allocating a scratch space for bpf helper arguments that are passed as constants or binary operations, as they need to be stored somewhere and then passed.
The mechanism I use there is not directly compatible with
printdue to the way we handle f-strings inprint(f-strings can only occur as an arg toprint, so we don't bother separating it's handling logic out toexpr_pass).Of course, there are ways to overcome these, that is the reason I am marking this issue as a wishlist item. But we must do this some time in the future for the sake of a more pythonic syntax.