On 15.06.2020 14:35, Reinoud Zandijk wrote:
> On Mon, Jun 15, 2020 at 02:06:00PM +0200, Kamil Rytarowski wrote:
>> On 15.06.2020 13:44, Reinoud Zandijk wrote:
>>> No need to install it in base. The resulting files can then be committed
>>> as `regen' just like the pcidevs variants.
>>
>> I disagree as we don't want to pull ${BSDSRCDIR} dependency for users, for
>> building an application.
>
> Lets try to make it clear then: who are the users?
>
> 1) Kernel syscall and compat (module) code; only when updating calls
>
> 2) ktrace (and friends) system calls decode. That would greatly increase
> readability ! Esp. if passed arguments could be automatically dumped too.
>
The above are good for TOOLDIR.
Below:
> 3) (llvm) fuzzers for testing; this is intree too so no big deal
>
LLVM is an external project and only in a special case part of the
basesystem. While there, there is the same issue with GCC sanitizers. We
definitely don't want to request regular LLVM or GCC users building the
toolchain to depend on TOOLDIR / BSDSRCDIR.
> 4) some syscall bashing tools for testing etc. They are tailored anyway so
> using a $BSDSRCDIR specfic program that is not installed is not that relevant.
>
I don't know what is syscall bashing tool for testing.
> But what else? There are IMHO no other valid users.
>
As of today GDB, but other similar programs can/shall follow.
syscall tracers (I wrote picotrace, truss - both distributed in pkgsrc;
there is strace)
Language runtime, basically everything that is not using libc could use
it (go, rust, D, etc).
kernel fuzzers (syzkaller)
We work on rumpkernel syscall fuzzers during the ongoing GSoC.
>> This utility shall receive ATF testing and thus shall be part of $PATH.
>
> ATF testing sounds like a good idea; but does an utility have to be installed
> to be able to test code?
>
Yes.
That could be worked around for ATF, but generally it needs testing.
> Also the generated files need to be updated in the kernel source tree and are
> tightly coupled to the kernel code templates.
>
Yes.
>> Putting it to /kern would be bad as we will gain another kernel ABI
>> dependency and this program won't be usable in TOOLDIR neither when working
>> with different target NetBSD release than the developer's computer.
>>
>> I personally think that the definition file shall be embedded directly into
>> the program to avoid any issues with incompatible script version vs
>> makesyscalls(1) program.
>
> You got a point there, and embedding it would make sense yes; but i still
> wouldn't install the program or its definition files as its kernel source
> version dependent and when building tools etc. $BSDSRCDIR is obviously
> available anyway.
>
For a developer it is fine to request BSDSRCDIR to be available, but for
users (of e.g. GDB) this is certainly an overkill. makesyscalls(1) will
be maybe up to 1MB. Just $BSDSRCDIR/sys takes around 450MB. If we want
to depend on BSDSRCDIR for programs in pkgsrc, this is IMO a blocker.
Prebuilt picotrace takes less than 100kb. Adding a hard dependency on
BSDSRCDIR would be severe overkill.
The intention of this tool is too export its functionality to regular
programs that can be built in pkgsrc and there are plenty of them.
> Reinoud
>
I'm definitely going to be a user of this program (in default PATH,
without BSDSRCDIR) and whenever possible, I will wire pkgsrc packages to
depend on it as soon as possible. None of the pkgsrc programs will need
BSDSRCDIR.
Attachment:
signature.asc
Description: OpenPGP digital signature