On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi <
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 ) (Laurent may confirm, or "unconfirm" that). The next shoudl be 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.
Aleksandar
> Maybe this is overthinking
> it, but it would give an idea of which ioctl() calls are relevant and
> missing from QEMU.
>
> Stefan