15:28 Uto, 28.01.2020. Laurent Vivier <[email protected]> је написао/ла: > > Le 27/01/2020 à 17:30, Aleksandar Markovic a écrit : > > > > > > On Mon, Jan 27, 2020 at 10:30 AM Stefan Hajnoczi <[email protected] > > <mailto:[email protected]>> 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 >
