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

[Stefan Hajnoczi]

On Thu, Jan 23, 2020 at 02:34:01PM +0100, Aleksandar Markovic wrote:
> *Extend support for ioctls in QEMU linux-user mode*
> 
> 
> 
> *PLANNED ACTIVITIES*
> 
> BACKGROUND
> 
> There is 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. However, these efforts have been
> usually done on a piece-by-piece basis, i a limited way covering a

s/ i / in /

> partucular need. This project will take more proactive stance, and try to

s/partucular/particular/

> improve QEMU before users start complaining.
> 
> PART I:
> 
>    a) Add strace support for outputing ioctl IDs (the second argument of
> ioctl()) as strings rather than numbers - for all platform independant
> ioctls.
>    b) 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.
> 
> 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)
> 
> PART III:
> 
>   a) Develop unit tests for selected ioctls that are already supported in
> QEMU.
> 
> 
> *DELIVERABLES*
> 
> The deliverables are in the form of source code for each part, intended to
> be upstreamed, and time needed for upstreaming (addressing reviews, etc.)
> process is included int this project.
> 
> The delivery of results can and should be distributed over larger period of
> time 2-3 months.

Good project idea.  Please choose concrete ioctls.  Applicants may not
have the necessary experience to choose a set of ioctls that are useful.

I wonder if it's possible to use something like the Debian popularity
contest (https://popcon.debian.org/) and then scan the source of the
most popular N packages for ioctl() calls.  Maybe this is overthinking
it, but it would give an idea of which ioctl() calls are relevant and
missing from QEMU.

Stefan

signature.asc
Description: PGP signature