> int ret = libwifi_get_wifi_frame(&frame, data, data_len, got_radiotap);
> ...
> int ret = libwifi_parse_beacon(&bss, &frame);
I haven't looked into the implementation, but if I understand correctly, the above code (extracted from the example on the home page) implies that the unparsed segment of `data` is either (1) copied into `frame` or (2) a pointer-span in `frame` references the unparsed segment of `data`. I wonder why either of these approaches have been taken. I imagine that the pointer-span could be computed (possibly even statically) inside `libwifi_parse_beacon` and `data` could also be passed:
> libwifi_parse_beacon(&bss, &frame, data);
This would shrink the size of `frame` and achieve zero-copy. Or perhaps I'm missing something.
Google’s Rule of Two [1] jumped out to me the moment I saw this combined with what seems to be a group of semi-anonymous authors on GitHub and this project while cool and a huge amount of work is also a bit of a yikes I think.
I know the common thinking is that “Fuchsia is dead” (it’s not check the repo it’s under heavy daily development) but it’s developing a new Rust based networking stack that’s really worth digging into [2] if that’s your idea of fun.
File extension reference notwithstanding, what an awful choice of vanity domain name. Depending on where you look .so isn’t even allowed to be used by non-Somali affiliates, and there are horror stories online of arbitrary non-renewals.
10 comments
[ 3.6 ms ] story [ 25.0 ms ] thread> int ret = libwifi_get_wifi_frame(&frame, data, data_len, got_radiotap);
> ...
> int ret = libwifi_parse_beacon(&bss, &frame);
I haven't looked into the implementation, but if I understand correctly, the above code (extracted from the example on the home page) implies that the unparsed segment of `data` is either (1) copied into `frame` or (2) a pointer-span in `frame` references the unparsed segment of `data`. I wonder why either of these approaches have been taken. I imagine that the pointer-span could be computed (possibly even statically) inside `libwifi_parse_beacon` and `data` could also be passed:
> libwifi_parse_beacon(&bss, &frame, data);
This would shrink the size of `frame` and achieve zero-copy. Or perhaps I'm missing something.
I know the common thinking is that “Fuchsia is dead” (it’s not check the repo it’s under heavy daily development) but it’s developing a new Rust based networking stack that’s really worth digging into [2] if that’s your idea of fun.
[1] https://chromium.googlesource.com/chromium/src/+/master/docs...
[2] https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/mai...