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

[Aleksandar Markovic]

15:28 Uto, 28.01.2020. Laurent Vivier <address@hidden> је написао/ла:
>
> 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?
>

The main difficilty, as I see this now, would be establishing a test bed. This should be possible using one or two USB flash drives (if one doesn't want to mess with own hard drives and partitions). After that, having dm-enabled devices available, writing unit test should be straightforward.

I don't have a particular prefference towards dm ioctls, they just look to me simple enough to be a good and gentle starting point for a beginner.

Giving a student a hard case at the beginning could be quite discouraging for him/her, and probably even counterproductive for the project as a whole.

Again, this is just my opinion, I don't have the ambition to impose such details. After all, this was and is just a proposal.

> > 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.
>

One more intriguing idea!

Regards,
Aleksandar

> Thanks,
> Laurent
>