Sorry for the top posting terse reply. On my phone as I'm in a meeting at work right now.
Anyway. Who here does not modify their path at login anyway. So arguments like "I need it in bin because I am going to use it a lot" seems like weak arguments. Think of what make sense for people that don't know much. For yourself whatever the location, you should not have a hard time to get it setup to work nicely for you. No matter where the binary ends up. Really. Johnny Kamil Rytarowski <[email protected]> skrev: (15 juni 2020 14:30:49 CEST) >On 15.06.2020 14:16, Johnny Billquist wrote: >> On 2020-06-15 14:12, Kamil Rytarowski wrote: >>> On 15.06.2020 14:11, Johnny Billquist wrote: >>>> >>>> We should not clutter the directories that are in the normal users >path >>>> with things that a normal user would never care about. >>> >>> I never used 90% of the programs from /usr/bin /usr/sbin /bin /sbin. >but >>> I definitely would use makesyscall(1). If you have other argument >that >>> "I don't use it" please speak up. >> >> I'm not convinced you are particularly representative of "users". >> > >NetBSD is a my daily driver so I'm a user! > >> But it would be interesting to hear how and when you are planning to >use >> makesyscalls. >> > >I work with the syscall layer almost continuously in various projects >(debuggers, fuzzers, syscall tracers, sanitizers, non-libc language >runtimes etc). Reiterating over the same list 10 times just increases >the frustration and perception of lost time of repeating the same >process in an incompatible way for another program. The tool shall >centralize the whole knowledge about passed arguments, structs and >export it to users through a flexible code generation. > >We already distribute to users /usr/include/sys/syscalls.h (and it is >used e.g. by GDB to parse the syscalls, as parsing syscalls.master in >that case was harder). makesyscalls(1) is intended to be a more >specialized and generic version of the same functionality as >distributed >by this header. > >With some sort of fanciness, we could generate these lists on the fly >in >some projects (for e.g. GDB) and we would want the utility to be >available in place. If it is restricted to build-only phase of various >programs (that definitely shall be free from BSDSRCDIR dependency) it >will be good enough. > >I'm for adding this program in PATH and I would be a user on a regular >basis. I basically need it for pretty everything (2 GSoC ongoing >projects are about covering the same syscalls in 2 different ways). >Asking me for a use-case is odd to me as it is an elementary program >that belongs to /usr/bin. > >> Johnny >> -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
