[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU lin
Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode
Mon, 27 Jan 2020 09:30:04 +0000
On Thu, Jan 23, 2020 at 02:34:01PM +0100, Aleksandar Markovic wrote:
> *Extend support for ioctls in QEMU linux-user mode*
> *PLANNED ACTIVITIES*
> 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
> 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
> 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
> 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.
Description: PGP signature
Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode, Peter Maydell, 2020/01/28
Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode, Aleksandar Markovic, 2020/01/30