Gsoc, Emulating missing linux syscalls
Hi! Sorry for such a late contact, I’ve already written a proper proposal for apply compat_linux project by following the instruction and guidelines from the link given by the NetBSD Gsoc idea list page.I try to answer as much questions as I can in the guidelines page and by follow the questions,i also try and compile the NetBSD kernel and read through the code base that relevant with compat_linux.And I think it’s very weird to apply Gsoc project and submit the proposal without having any contact with the developer/maintainer of the project.So anyways, sorry for dragging this till now. As a junior developer I’ve been working on several open source project on GitHub with the git/github pr workflow before,but as I read through the NetBSD contribute guidelines page, it seems the traditional mail list and problem database /problem report is the way to collaborate in NetBSD,so is it a “must do” here to use the cvs/svn version control software and the mail list for contribute here? In the compat_linux project page, saying that "you should find at least one Linux binary that does not yet run on NetBSD using compat_linux to use as a test case (your mentor may have suggestions)” Is there any suggestion on which linux binary isn’t yet supported by compat_linux as a test case?
Inquiry about the "Auto Create Swap on Memory Pressure" Project in GSoC
Dear Mentors, I am interested in the "Auto Create Swap on Memory Pressure" project (https://wiki.netbsd.org/projects/project/swap-auto/) in GSoC. I would greatly appreciate it if you could inform me whether there is an existing suitable candidate for this project at the moment. If no one has been chosen yet, could you provide me with the requirements necessary for participating in this project? I am eager to learn more about this exciting opportunity. Best Regards, Tengfei Yu
Re: MCLADDREFERENCE() incrementing the wrong ext_refcnt?
> So I think > atomic_inc_uint(&(o)->m_ext.ext_refcnt);\ > should really be > atomic_inc_uint(&(o)->m_ext_ref->m_ext.ext_refcnt); \ > which, of course, is the same thing if MEXT_ISEMBEDDED(o) is true. > Am I getting something wrong? Self-answer: Yes. m_ext is m_ext_ref->m_ext_storage, so the additional indirection is already performed.
[GSoC] Questions about emulating missing linux system calls project
Hello, For the past few days, I have been trying to assess support for Linux system calls on a NetBSD system. I am using Linux Test Project for identifying system calls that are yet to be emulated on NetBSD. I have setup QEMU with GENERIC kernel for testing purpose (Thanks iMil for helping me out!) with COMPAT_LINUX option enabled. I have following particular questions: 1. I wish to emulate support for pidfd_* family of system calls, open_tree, openat2, clone3. I believe they still lack emulation support. Where should I look to identify the possible mappings for these system calls in NetBSD kernel? 2. I found around 40 system calls that currently lack emulation support. Most of them are the system calls that aren't popular or are more relevant to Linux kernel. Only some of the newer system calls seem more likely to be able to be mapped directly to NetBSD system calls. Is it expected to actually implement some of them in NetBSD kernel and then add them to compat layer as part of this project? Also, what's the state of splice and sendfile system calls? I can see that they have been implemented as part of GSoC 2022 but the test cases relating to them still can't find these system calls. 1. With respect to system calls relating to scheduler, I get error relating to not finding some particular files in proc directory. I have set up proc as mentioned in documentation but I still get these errors when I run schedular related system calls. Does proc need to be configured in different way or do schedular related system calls actually lack emulation support? I would also like to thank Theodore for helping me understand the work he did last year. Thanking you, Shivraj
