On 14.06.2020 23:59, Johnny Billquist wrote: > On 2020-06-14 23:21, Paul Goyette wrote: >> On Sun, 14 Jun 2020, David Holland wrote: >> >> <snip> >> >>> This raises two points that need to be bikeshedded: >>> >>> (1) What's the new tool called, and where does it live in the tree? >>> "usr.bin/makesyscalls" is fine with me but ymmv. >> >> "usr.bin/makesyscalls" sounds good to me. > > Uh? usr.bin is where stuff for /usr/bin is located, right? Anything > there should be pretty normal tools that any user might be interested > in. Don't seem to me as makesyscalls would be a tool like that? > > Possibly some sbin thing, but in all honestly, wouldn't this make more > sense to have somewhere under sys? Don't we have some other tools and > bits which are specific for kernel and library building? > /usr/bin is appropriate and there are already similar tools (like ioctlprint(1)). It's already in PATH and definitely in interest of some end-users (like me) and I do want to have it. makesyscalls(1) sounds like a good name. /usr/share/sys/syscalls.de should be an internal detail for makesyscalls(1). I actually think that syscalls.def should be builtin into the program and we should avoid an external file dependency as it is expected to be operational for only one kernel ABI release + makesyscalls(1) version. There are expected no external consumers of this .def file and all we need and want is to pass rules how to generate syscall definitions. makesyscalls(1) will likely quickly turn into a ./build.sh tool and reducing management of an external file is especially a good idea. There is already a prior art as ioctlprint(1) has a builtin database for the ioctl codes and it works well. > Johnny >
Attachment:
signature.asc
Description: OpenPGP digital signature