Re: [Qemu-devel] Submit your Google Summer of Code project ideas and volunteer to mentor

[John Snow <jsnow@redhat.com>]

On 01/27/2015 07:48 AM, Hannes Reinecke wrote:
> On 01/23/2015 06:21 PM, Stefan Hajnoczi wrote:
>> Dear libvirt, KVM, and QEMU contributors,
>> The Google Summer of Code season begins soon and it's time to collect
>> our thoughts for mentoring students this summer working full-time on
>> libvirt, KVM, and QEMU.
>>
>> What is GSoC?
>> Google Summer of Code 2015 (GSoC) funds students to
>> work on open source projects for 12 weeks over the summer.  Open
>> source organizations apply to participate and those accepted receive
>> funding for one or more students.
>>
>>
>> We now need to collect a list of project ideas on our wiki.  We also
>> need mentors to volunteer.
>>
>> http://qemu-project.org/Google_Summer_of_Code_2015
>>
>> Project ideas
>> Please post project ideas on the wiki page below.  Project ideas
>> should be suitable as a 12-week project that a student fluent in
>> C/Python/etc can complete.  No prior knowledge of QEMU/KVM/libvirt
>> internals can be assumed.
>>
> I'm not the most active of contributors, but here's an idea:
>
> Project idea: Integrate ide ATAPI and scsi CD-ROM driver
>
> Currently the ide ATAPI and scsi CD-ROM driver are two
> distinct implementations, and have different bugs/features.
> This leads to the situation that things which work when using the IDE
> emulation don't work when using the SCSI emulation and vice versa.
> So this project is for implementing a virtual ATA-to-SCSI bridge
> in qemu, use this for emulating an IDE ATAPI drive, and merging the
> missing features from the IDE implementation into the SCSI one.
>
> Skill level: intermediate
>
> (This would also help to implement advanced features like NCQ autosense
> or sense data reporting in the ATA emulation. Just in case someone's
> daft enough trying to implement a ZAC emulation ...).
>
> And yes, I'd be willing to mentor it.
>
> Cheers,
>
> Hannes
>

This would be very cool, and it might help make our admittedly weak 
ATAPI support stronger.

I've asked Paolo before if he thought I should try to merge the ATAPI 
and SCSI code, but he passed on the idea at the time. Might be something 
a GSoC student could take a stab at, though the maze of SCSI, IDE and 
ATAPI specs can be a little difficult to navigate at times.

If a bridge was designed to replace the current ATAPI code entirely, it 
would need to have some inter-operability with the AHCI code, which has 
its own unique quirks that we need to be mindful of.

It might wind up being a bit of a tall order, but it could be good fun.

--js