On Tue, Jan 28, 2020 at 7:00 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Tue, 28 Jan 2020 at 17:51, Aleksandar Markovic > <aleksandar.m.m...@gmail.com> wrote: > > > > I am personally interested in both. However, learning about syscalls and > implementation of support for them in QEMU would require more ramp-up time > from student (as is the case for any new employee in a similar situation > for that matter). In the worst case, the student would spend much more time > on learning than on productive work. My impression is at it is better to > leave the student focused on just one area - ioctl support. > > I think they're about the same, really. The level of difficulty is more > in what the syscall or ioctl does and what its arguments are (ie does > QEMU have to do much mangling on the way past) rather than whether > it happens to be a syscall or an ioctl. Some syscalls are hard, but > some are trivial; same with ioctls. > > thanks > -- PMM > How about this: - I removed the first item (a) of PART I (since I already have an idea how to do this in, I think, a very good way), to free the student time. I will send my solution to the list before this summer, I hope. - I amended all parts to include some syscall-related activities - and the end result is this: *Extend support for ioctls and syscalls in QEMU linux-user mode* *PLANNED ACTIVITIES* BACKGROUND There are currently 2500+ ioctls defined in Linux kernel. QEMU linux-user currently supports only several hundred. There is a constant need for expanding ioctl support in QEMU. Users use Linux-user mode in variety of setups (for example, building and testing tools and applications under chroot environment), and, on a regular basis, efforts by multiple people are made to fill in missing support. Regarding syscall support in QEMU linux-user, the coverage is much better than in case of ioctls. However, kernel syscall interface continuously develops and grows, and QEMU linux-user support usually lags considerably. The support for new syscalls is usually left unimplemented, until an end user reports that it is missing in hers/his usage scenario. In conclusion, the efforts for supporting ioctls and syscalls in QEMU have usually been done on a piece-by-piece basis, in a limited way covering a particular need. This project will take more proactive stance, and try to improve QEMU before users start complaining. This contributions of this project will be mostly to QEMU, but some parts would be also contirbutions to LTP (Linux Test Project). PART I: a) Add strace support for printing the third argument of ioctl() (be it int, string, structure or array) - limited to selected ioctls that are frequently used. b) Add strace support for printing the arguments of selected syscalls that are frequently used, and not covered in QEMU strace module so far. PART II: a) Amend support for existing groups of ioctls that are not completed 100% (let's say, filesystem ioctls) b) Add support for a selected group of ioctls that are not currently supported (for example, DM ioctls, Bluetooth ioctls, or Radeon DRM ioctls) c) Add support for a selected group of syscalls that were recently introduced in kernel. PART III: a) Within LTP (Linux Test Project), develop unit tests for selected ioctls that are supported in QEMU (including some whose support is developed in PART II). b) Within LTP (Linux Test Project), develop unit tests for selected syscalls that are supported in QEMU (including some whose support is developed in PART II). *DELIVERABLES* The deliverables are in the form of source code for each part, intended to be upstreamed to either QEMU or LTP open source projects. The time needed for upstreaming (addressing reviews, etc.) process is included into this project. The delivery of results can and should be distributed over larger period of time (2-3 months). Mentor: open (I propose Laurent Vivier) Student: open
