qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU lin


From: Laurent Vivier
Subject: Re: [GSoC/Outreachy QEMU proposal] Extend support for ioctls in QEMU linux-user mode
Date: Thu, 30 Jan 2020 12:20:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

Le 30/01/2020 à 12:09, Aleksandar Markovic a écrit :
> 14:34 Čet, 23.01.2020. Aleksandar Markovic <address@hidden
> <mailto:address@hidden>> је написао/ла:
>>
>> 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 partucular need. This project will take more proactive
> stance, and try to 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.
>>
>>
>> Montor: open (I propose Laurent Vivier)
>>
>> Student: open
> 
> Hello, Peter, Laurent, Stefan.
> 
> I presented in this thread two variants of a potential
> linux-user-related project for GSoC/Outreachy. The first variant is more
> focused on a particular area (ioctl support), while the second one
> covers wider set of current issues within linux-user. The pros and cons
> of both should be carefully assesed. I will leave to Peter and Laurent
> the final judgement if we want to go or not with this project and also
> the final formulation of the project.

I think the second variant (that includes new syscalls) is more
interesting for us and for the student.

> Stefan, there was an idea in this thread that this project contributes
> (apart to QEMU) to another ooen source project (LTP). In my layman view,
> this is an advantage. But, how does that fit into GSoC/Outreachy rules?
> 
> Laurent, all this seems to be dependant on whether you are ready to
> mentor the project. Are you?

Yes, of course.

> The deadline for submitting GSoC/Outreachy projects (within QEMU) is
> just around the corner (Feb 1). I leave to Laurent or Peter (should they
> give "go" to this proposal) to officially submit the project on our wiki
> page created for that purpose, in the form they deem the best.

Peter, is it ok for you?

Thanks,
Laurent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]