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

[Laurent Vivier]

Le 27/01/2020 à 17:30, Aleksandar Markovic a écrit :
> 
> 
> On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi <address@hidden
> <mailto:address@hidden>> wrote:
>>
>> 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.
>>
> 
> PART I should not be that difficult. PART II is, however, a minefield.
> An implementation of support of a ioctl range from 15 minutes to two
> months. The least we wont to happen is that the student is stuck with a
> problem for months. Therefore I suggest first some "low hanging fruit"
> for a student to get self-confidence and experience. One such group is
> DM ioctl group ( link
> <https://github.com/torvalds/linux/blob/master/include/uapi/linux/dm-ioctl.h#L251>
> ) (Laurent may confirm, or "unconfirm" that). The next shoudl be

Well, ioctl are generally implemented on demand when we see there is one
missing. DM can be interresting, but do we have an easy way to test them?

> something a little harder, but useful in terms of end user. PART III
> should be developed on the fly, but we need to provide a
> guideline/framework prior to starting working with a student, IMHO..
> 
>> 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.
> 
> Great! I'll try. A very interesting site and method.
> 

The other point to implement ioctl that we know are used by a given
package is we can run this package to see if it works or not before and
after the implementation of the missing ioctl.

We can also rely on some test suites provided by the packages.

We can also detect missing ioctl by looking at "Unsupported ioctl: cmd="
error message while we run chroot.

It could be interesting to run a gnome-session from inside a chroot with
qemu-linux-user to trigger more multimedia related ioctl.

Thanks,
Laurent