On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi <stefa...@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 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
