Dmitry Vyukov

One thing that may be useful and possible with smarter code analysis: detecting unused/reserved/padding fields (esp in structs, but may be direct syscall args too). These either appear unused in...

FTR here is an interface extraction utility for NetBSD, can extract ioctl definitions: https://github.com/ais2397/sys2syz

For fuchsia there is fidlgen: https://fuchsia.googlesource.com/fuchsia/+/4ad0d5717d65/tools/fidl/fidlgen_syzkaller/main.go

For netlink we could consider extracting info from ynl project once it's merged upstream: https://github.com/kuba-moo/ynl/blob/main/Documentation/netlink/specs/fou.yaml It contains machine-readable descriptions of netlink protocols. However, it needs to cover more protocols and...

> Switch our urls from being root-relative (starting with /) to being just path relative (starting with ./). This would be the simplest solution, but potentially we might have problems...

> > What's the problem with "deep http endpoints"? > > If we ever need to render some HTML output at `/a/b`, then links to other endpoints would have to...

Relative paths don't add code nor user burden. It's equivalent code/complexity that just supports more use cases. While prefix is more code/complexity. One can buy everything with more code, but...

> Anyway I think that using some new option like `http-prefix` is a good idea because: > > 1. Introducing multilevel HTTP links in future will break relative addressing. What's...

> When we click on config/verbose relative url on home page, we go to http://test/syzkaller/config/verbose, so how can you generate on this HTML page url to http://test/syzkaller to get homepage...

> Okay, but anyway in both cases we will add code for url-prefix or new http router Why do we need to do anything with http router? We will have...