From: Laurent Vivier <laurent@vivier.eu>
To: Aleksandar Markovic <aleksandar.m.mail@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode
Date: Tue, 28 Jan 2020 15:28:01 +0100 [thread overview]
Message-ID: <74b19db2-8ed2-c0c4-2870-b60dd49789cd@vivier.eu> (raw)
In-Reply-To: <CAL1e-=h+g4FWVDVe6a4T_X_nEA-catKd+7LiKXx++qS+G7mqOQ@mail.gmail.com>
Le 27/01/2020 à 17:30, Aleksandar Markovic a écrit :
>
>
> On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi <stefanha@redhat.com
> <mailto:stefanha@redhat.com>> 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
next prev parent reply other threads:[~2020-01-28 14:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 13:34 [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode Aleksandar Markovic
2020-01-27 9:30 ` Stefan Hajnoczi
2020-01-27 16:30 ` Aleksandar Markovic
2020-01-28 14:28 ` Laurent Vivier [this message]
2020-01-28 17:32 ` Aleksandar Markovic
2020-01-28 17:37 ` Laurent Vivier
2020-01-28 14:32 ` Peter Maydell
2020-01-28 17:51 ` Aleksandar Markovic
2020-01-28 18:00 ` Peter Maydell
2020-01-28 20:48 ` Aleksandar Markovic
2020-02-05 11:16 ` Stefan Hajnoczi
2020-02-05 13:44 ` Laurent Vivier
2020-01-30 11:09 ` Aleksandar Markovic
2020-01-30 11:20 ` Laurent Vivier
2020-01-30 11:52 ` Peter Maydell
2020-01-31 8:37 ` Laurent Vivier
2020-02-05 10:45 ` Stefan Hajnoczi
2020-01-31 11:28 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74b19db2-8ed2-c0c4-2870-b60dd49789cd@vivier.eu \
--to=laurent@vivier.eu \
--cc=aleksandar.m.mail@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).