Le 28/01/2020 à 18:32, Aleksandar Markovic a écrit : > 15:28 Uto, 28.01.2020. Laurent Vivier <laur...@vivier.eu > <mailto:laur...@vivier.eu>> је написао/ла: >> >> Le 27/01/2020 à 17:30, Aleksandar Markovic a écrit : >> > >> > >> > On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi > <stefa...@redhat.com <mailto:stefa...@redhat.com> >> > <mailto:stefa...@redhat.com <mailto: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 >> >> 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
