Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode

[Aleksandar Markovic]

On Tue, Jan 28, 2020 at 7:00 PM Peter Maydell <address@hidden> wrote:

On Tue, 28 Jan 2020 at 17:51, Aleksandar Markovic
<address@hidden> 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