On Wed, Aug 02, 2023 at 05:17:45AM +1000, matthew green wrote:
> have we considered checking in tiny binaries actually built for
> the emulation and using them?
I'm fine with that, as long as we have some setup to reproduce the binaries
easily/reliably. Sometimes we discover bugs in the tests and
have we considered checking in tiny binaries actually built for
the emulation and using them?
various methods discussed so far have their own advantages, but
this is the only way that tests actual binaries built for eg
linux and run with compat_linux. anything else is limited in
it's ability to
On Tue, Aug 01, 2023 at 12:43:50PM -0400, Theodore Preduta wrote:
> My understanding of the "without Linux dev tools and libs around" part
> is that each test case would be a separate (static Linux) binary that is
> just a main() that only directly calls syscalls.
Yes.
> And then I guess
On 2023-08-01 12:15, Emmanuel Dreyfus wrote:
> On Tue, Aug 01, 2023 at 05:52:57PM +0200, Martin Husemann wrote:
>> Yes we are. But the question is if we can create (tiny) test binaries
>> just for this purpose, without Linux dev tools and libs around,
>> from within a standard build.sh run.
>
>
On Tue, Aug 01, 2023 at 05:52:57PM +0200, Martin Husemann wrote:
> Yes we are. But the question is if we can create (tiny) test binaries
> just for this purpose, without Linux dev tools and libs around,
> from within a standard build.sh run.
You could craft a NetBSD binary that abuses the
On Tue, Aug 01, 2023 at 11:48:21AM -0400, Theodore Preduta wrote:
> I don't think so. If the binary starts under Linux emulation then the
> kernel will expect that the syscall arguments follow Linux's calling
> convention. (Which I guess could be done, but, correct me if I'm wrong,
> are we not
On 2023-08-01 07:04, Valery Ushakov wrote:
> On Tue, Aug 01, 2023 at 12:39:46 +0200, Martin Husemann wrote:
>
>> On Tue, Aug 01, 2023 at 01:34:54PM +0300, Valery Ushakov wrote:
>>> As for testing emulated syscalls - can we solve this problem with a
>>> bit of elf branding to convince the kernel
> Date: Mon, 31 Jul 2023 22:29:29 +0100
> From: Robert Swindells
>
> Theodore Preduta wrote:
> > This comes somewhat as a "part 2" to
> > https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
> >
> > Given the responses to that thread, I decided to add native stubs
> > for epoll
On Tue, Aug 01, 2023 at 12:39:46 +0200, Martin Husemann wrote:
> On Tue, Aug 01, 2023 at 01:34:54PM +0300, Valery Ushakov wrote:
> > As for testing emulated syscalls - can we solve this problem with a
> > bit of elf branding to convince the kernel to start the binary under
> > emulation directly?
On Tue, Aug 01, 2023 at 01:34:54PM +0300, Valery Ushakov wrote:
> As for testing emulated syscalls - can we solve this problem with a
> bit of elf branding to convince the kernel to start the binary under
> emulation directly? Inventing a whole new backdoor API for that seems
> kinda an overkill.
On Tue, Aug 01, 2023 at 08:16:50 +0200, Martin Husemann wrote:
> On Mon, Jul 31, 2023 at 05:03:48PM -0400, Theodore Preduta wrote:
> > One idea (mentioned in the original thread) would be to introduce a
> > syscall along the lines of
> >
> > int emul_syscall(const char *emul_name, int
On Mon, Jul 31, 2023 at 05:03:48PM -0400, Theodore Preduta wrote:
> One idea (mentioned in the original thread) would be to introduce a
> syscall along the lines of
>
> int emul_syscall(const char *emul_name, int number, ...)
>
> which executes a single syscall. The flaw with this idea is
On 2023/08/01 6:29, Robert Swindells wrote:
Theodore Preduta wrote:
This comes somewhat as a "part 2" to
https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
Given the responses to that thread, I decided to add native stubs
for epoll (the fact epoll is widespread alone
Theodore Preduta wrote:
> This comes somewhat as a "part 2" to
> https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
>
> Given the responses to that thread, I decided to add native stubs
> for epoll (the fact epoll is widespread alone justifies it, but it has
> already had some
This comes somewhat as a "part 2" to
https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html
Given the responses to that thread, I decided to add native stubs
for epoll (the fact epoll is widespread alone justifies it, but it has
already had some negative side effects, see:
15 matches
Mail list logo
