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

[Laurent Vivier]

Le 28/01/2020 à 18:32, Aleksandar Markovic a écrit :
> 15:28 Uto, 28.01.2020. Laurent Vivier <address@hidden
> <mailto: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>
>> > <mailto: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.

The easiest way to test DM is to use a qemu-system-x86_64/kvm VM with
several storage files and to run qemu-user inside. And a VM is easier to
restore when we break it... and it will happen.

Thanks,
Laurent