Re: [Spice-devel] Identifying and removing potentially divisive language
> Well... Your examples are contradicting: the "master/slave" relation used in > electronics or psychology are re-using the slavery concepts too... This > doesn't make it right :-) That depends on the etymology and history, not an expert on this. I think there's a mild root, but still this require some technical language explanation. They can contradict only if they came from 2 separate roots, if this is true is means the there are multiple concepts involved not only one. > Now I'm not working in electronics or psychology, so I'm not going to try and > change their wording. > Regarding changing it now rather than waiting: Daniel is mentioning two hints > - git, or github. As our code is hosted in gitlab, I would add that one too > :) > The idea being that if they choose a new word, it will become the new > default, and we could align with them for consistency, rather than arguing > among us and picking a potentially different name It makes sense, but more at Gitlab level, not a world global de-facto for me > This doesn't prevent us from changing words that are in our code (like > blacklist/whitelist?). I think there's not a lot of them. > Regards, > Julien > Le jeu. 2 juil. 2020 à 16:09, Frediano Ziglio < fzig...@redhat.com > a écrit > : > > > On Wed, Jul 01, 2020 at 04:15:07PM +0200, Victor Toso wrote: > > > > > Hi, > > > > > > > > > > On Wed, Jul 01, 2020 at 10:03:10AM +0200, Kevin Pouget wrote: > > > > > > Hello SPICE community, > > > > > > > > > > > > following Chris Wright (Red Hat CTO) blog post on "Making open > > > > > > source more inclusive by eradicating problematic language" [1], > > > > > > I would like to suggest that we have a look at SPICE source > > > > > > code to find out if/where such language is used and how to > > > > > > remove it. > > > > > > > > > > > > To illustrate the motivations of this move, consider the phrase > > > > > > "the final solution". I am quite sure you would agree that > > > > > > these words cannot be used inside a project. You would agree > > > > > > because the WWII events are still in minds and not so ancient > > > > > > yet. Git "master", or the "master/slave" pattern may not > > > > > > trigger similar thoughts if your ancestors didn't suffer > > > > > > slavery; "whitelist/blacklist" neither, if the color of your > > > > > > skin doesn't get you into trouble (white=allow, black=deny). > > > > > > Overall, I would advise, when thinking about these questions, > > > > > > not to forget on which side your history/country/skin > > > > > > color/sexual orientation sits you. If it's the oppressor side, > > > > > > you're not at the right place to say it's not relevant. > > > > > > > > > > > > --- > > > > > > > > > > > > I had a quick `grep` look at SPICE code base, searching for > > > > > > `blacklist/whitelist/slave` and I could only find very few > > > > > > occurrences of these words, which is nice. Can you find other > > > > > > problem words? > > > > > > > > > > > > `master` is used for git default's branch, but not much > > > > > > elsewhere. Let's discuss if we could get rid of this one, for > > > > > > instance changing it to `main` (just a suggestion). I don't > > > > > > think that it can break that many things (only the CI comes to > > > > > > my mind, where the `master` branch may be treated differently) > > > > > > as git name default branch's name is often omitted in the usual > > > > > > workflows. > > > > > > > > > > > > Please share your thoughts about this > > > > > > > > > > Not a native english speaker but I've read a few discussions > > > > > around the user of master as git as in master copy instead of > > > > > master/slave. Another examples of the use of master from native > > > > > speakers included master as in school teacher or someone that is > > > > > in charge of something (the offense being where the subject of > > > > > control is the slave). > > > > > > > > > > Still, I don't really mind to changing it to main, even more if > > > > > there are people that feel this can really be offensive in some > > > > > way.. > > > > > > > > I think the primary downside in changing the branch name is if we > > > > end up with different branch names chosen by each project. There is > > > > value in the fact that essentially every project uses the same > > > > branch name for their latest development branch, as it gives end > > > > users consistent expectations. > > > > > > > > I'm in favour of changing the branch name, but my inclination is > > > > to wait and see a little longer, in order to identify what the > > > > new defacto standard ends up being. "main" is a good bet as a new > > > > standard, but it would be nice to see it "in action". > > > > > > > > I'd be looking for two possible signs > > > > > > > > Whether the Git maintainers themselves decide to standardize > > > > on a new term. > > > > > > > > What GitHub actually decide upon & roll out. > > > > >
Re: [Spice-devel] [PATCH RFC v4 0/1] Virtio Video Device Specification
On Fri, Jul 3, 2020 at 6:18 PM Michael S. Tsirkin wrote: > > On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote: > > Hi Dmitry, > > > > On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp > > wrote: > > > > > > Hi Keiichi, > > > > > > Thanks for the clarification. I believe we should explicitly describe > > > this in > > > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a > > > problem > > > there. If it is a guest allocated resource, we cannot consider it to be > > > free > > > until the device really releases it. And it won't happen until we issue > > > the > > > next ATTACH call. Also, as we discussed before, it might be not possible > > > to > > > free individual buffers, but the whole queue only. > > > > In the case of the encoder, a V4L2 driver is not supposed to let > > user-space dequeue an input frame while it is used as reference for > > the encoding process. So if we add a similar rule in the virtio-video > > specification, I suppose this would solve the problem? > > > > For the decoder case, we have a bigger problem though. Since DMABUFs > > can be arbitrarily attached to any V4L2 buffer ID, we may end up > > re-queueing the DMABUF of a decoded frame that is still used as > > reference under a different V4L2 buffer ID. In this case I don't think > > the driver has a way to know that the memory resource should not be > > overwritten, and it will thus happily use it as a decode target. The > > easiest fix is probably to update the V4L2 stateful specification to > > require that reused DMABUFs must always be assigned to the same V4L2 > > buffer ID, and must be kept alive as long as decoding is in progress, > > or until a resolution change event is received. We can then apply a > > similar rule to the virtio device. > > > Sounds like a generic kind of problem - how do other devices solve it? Most users of V4L2 drivers use MMAP buffers, which don't suffer from this problem: since MMAP buffers are managed by V4L2 and the same V4L2 buffer ID always corresponds to the same backing memory, the driver just needs to refrain from decoding into a given V4L2 buffer as long as it is used as a reference frames. This is something that all drivers currently do AFAICT. The problem only occurs if you let userspace map anything to V4L2 buffers (USERPTR or DMABUF buffers). In order to guarantee the same reliable behavior as with MMAP buffers, you must enforce the same rule: always the same backing memory for a given V4L2 buffer. ... or you can rotate between a large enough number of buffers to leave enough space for the reference tag to expire on your frames, but that's clearly not a good way to address the problem. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC v4 0/1] Virtio Video Device Specification
On Fri, Jul 3, 2020 at 11:27 AM Alexandre Courbot wrote: > > On Fri, Jul 3, 2020 at 6:18 PM Michael S. Tsirkin wrote: > > > > On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote: > > > Hi Dmitry, > > > > > > On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp > > > wrote: > > > > > > > > Hi Keiichi, > > > > > > > > Thanks for the clarification. I believe we should explicitly describe > > > > this in > > > > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a > > > > problem > > > > there. If it is a guest allocated resource, we cannot consider it to be > > > > free > > > > until the device really releases it. And it won't happen until we issue > > > > the > > > > next ATTACH call. Also, as we discussed before, it might be not > > > > possible to > > > > free individual buffers, but the whole queue only. > > > > > > In the case of the encoder, a V4L2 driver is not supposed to let > > > user-space dequeue an input frame while it is used as reference for > > > the encoding process. So if we add a similar rule in the virtio-video > > > specification, I suppose this would solve the problem? > > > > > > For the decoder case, we have a bigger problem though. Since DMABUFs > > > can be arbitrarily attached to any V4L2 buffer ID, we may end up > > > re-queueing the DMABUF of a decoded frame that is still used as > > > reference under a different V4L2 buffer ID. In this case I don't think > > > the driver has a way to know that the memory resource should not be > > > overwritten, and it will thus happily use it as a decode target. The > > > easiest fix is probably to update the V4L2 stateful specification to > > > require that reused DMABUFs must always be assigned to the same V4L2 > > > buffer ID, and must be kept alive as long as decoding is in progress, > > > or until a resolution change event is received. We can then apply a > > > similar rule to the virtio device. > > > > > > Sounds like a generic kind of problem - how do other devices solve it? > > Most users of V4L2 drivers use MMAP buffers, which don't suffer from > this problem: since MMAP buffers are managed by V4L2 and the same V4L2 > buffer ID always corresponds to the same backing memory, the driver > just needs to refrain from decoding into a given V4L2 buffer as long > as it is used as a reference frames. This is something that all > drivers currently do AFAICT. > > The problem only occurs if you let userspace map anything to V4L2 > buffers (USERPTR or DMABUF buffers). In order to guarantee the same > reliable behavior as with MMAP buffers, you must enforce the same > rule: always the same backing memory for a given V4L2 buffer. > > ... or you can rotate between a large enough number of buffers to > leave enough space for the reference tag to expire on your frames, but > that's clearly not a good way to address the problem. FWIW, it's typically solved with regular devices by completely disallowing the DMABUF/USERPTR modes and only allowing the V4L2-managed MMAP mode for affected buffer queues. However, that's quite a severe limitation and with a careful API extension, DMABUF could be still handled. Namely: - pre-registration of buffers at initialization time: that would likely mean mandating VIDIOC_QBUF for all indexes before any decoding/encoding can start, - enforcement of index-buffer mapping: VIDIOC_QBUF would have to fail if one attempts to queue another buffer at the same index, - ability to explicitly release existing buffers: there is VIDIOC_RELEASE_BUF in the works which could be used to release a specific index, - ability to explicitly add new buffers: a combination of VIDIOC_CREATEBUFS + VIDIOC_QBUF could be already used to achieve this. Best regards, Tomasz ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC v4 0/1] Virtio Video Device Specification
On Fri, Jul 03, 2020 at 02:45:15PM +0900, Alexandre Courbot wrote: > Hi Dmitry, > > On Thu, Jul 2, 2020 at 10:47 PM Dmitry Sepp > wrote: > > > > Hi Keiichi, > > > > Thanks for the clarification. I believe we should explicitly describe this > > in > > the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH section. And I also still see a problem > > there. If it is a guest allocated resource, we cannot consider it to be free > > until the device really releases it. And it won't happen until we issue the > > next ATTACH call. Also, as we discussed before, it might be not possible to > > free individual buffers, but the whole queue only. > > In the case of the encoder, a V4L2 driver is not supposed to let > user-space dequeue an input frame while it is used as reference for > the encoding process. So if we add a similar rule in the virtio-video > specification, I suppose this would solve the problem? > > For the decoder case, we have a bigger problem though. Since DMABUFs > can be arbitrarily attached to any V4L2 buffer ID, we may end up > re-queueing the DMABUF of a decoded frame that is still used as > reference under a different V4L2 buffer ID. In this case I don't think > the driver has a way to know that the memory resource should not be > overwritten, and it will thus happily use it as a decode target. The > easiest fix is probably to update the V4L2 stateful specification to > require that reused DMABUFs must always be assigned to the same V4L2 > buffer ID, and must be kept alive as long as decoding is in progress, > or until a resolution change event is received. We can then apply a > similar rule to the virtio device. Sounds like a generic kind of problem - how do other devices solve it? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Identifying and removing potentially divisive language
On Fri, Jul 3, 2020 at 9:03 AM Frediano Ziglio wrote: > > Well... Your examples are contradicting: the "master/slave" relation used > in electronics or psychology are re-using the slavery concepts too... This > doesn't make it right :-) > > That depends on the etymology and history, not an expert on this. > I think there's a mild root, but still this require some technical > language explanation. > They can contradict only if they came from 2 separate roots, if this is > true is means the there are multiple concepts involved not only one. > > Now I'm not working in electronics or psychology, so I'm not going to try > and change their wording. > > Regarding changing it now rather than waiting: Daniel is mentioning two > hints - git, or github. As our code is hosted in gitlab, I would add that > one too :) > The idea being that if they choose a new word, it will become the new > default, and we could align with them for consistency, rather than arguing > among us and picking a potentially different name > > It makes sense, but more at Gitlab level, not a world global de-facto for > me > I agree that it makes sense to wait for gitlab or git projects decide > This doesn't prevent us from changing words that are in our code (like > blacklist/whitelist?). I think there's not a lot of them. > > Regards, > Julien > > > Le jeu. 2 juil. 2020 à 16:09, Frediano Ziglio a > écrit : > >> >> > On Wed, Jul 01, 2020 at 04:15:07PM +0200, Victor Toso wrote: >> > > Hi, >> > > >> > > On Wed, Jul 01, 2020 at 10:03:10AM +0200, Kevin Pouget wrote: >> > > > Hello SPICE community, >> > > > >> > > > following Chris Wright (Red Hat CTO) blog post on "Making open >> > > > source more inclusive by eradicating problematic language" [1], >> > > > I would like to suggest that we have a look at SPICE source >> > > > code to find out if/where such language is used and how to >> > > > remove it. >> > > > >> > > > To illustrate the motivations of this move, consider the phrase >> > > > "the final solution". I am quite sure you would agree that >> > > > these words cannot be used inside a project. You would agree >> > > > because the WWII events are still in minds and not so ancient >> > > > yet. Git "master", or the "master/slave" pattern may not >> > > > trigger similar thoughts if your ancestors didn't suffer >> > > > slavery; "whitelist/blacklist" neither, if the color of your >> > > > skin doesn't get you into trouble (white=allow, black=deny). >> > > > Overall, I would advise, when thinking about these questions, >> > > > not to forget on which side your history/country/skin >> > > > color/sexual orientation sits you. If it's the oppressor side, >> > > > you're not at the right place to say it's not relevant. >> > > > >> > > > --- >> > > > >> > > > I had a quick `grep` look at SPICE code base, searching for >> > > > `blacklist/whitelist/slave` and I could only find very few >> > > > occurrences of these words, which is nice. Can you find other >> > > > problem words? >> > > > >> > > > `master` is used for git default's branch, but not much >> > > > elsewhere. Let's discuss if we could get rid of this one, for >> > > > instance changing it to `main` (just a suggestion). I don't >> > > > think that it can break that many things (only the CI comes to >> > > > my mind, where the `master` branch may be treated differently) >> > > > as git name default branch's name is often omitted in the usual >> > > > workflows. >> > > > >> > > > Please share your thoughts about this >> > > >> > > Not a native english speaker but I've read a few discussions >> > > around the user of master as git as in master copy instead of >> > > master/slave. Another examples of the use of master from native >> > > speakers included master as in school teacher or someone that is >> > > in charge of something (the offense being where the subject of >> > > control is the slave). >> > > >> > > Still, I don't really mind to changing it to main, even more if >> > > there are people that feel this can really be offensive in some >> > > way.. >> > >> > I think the primary downside in changing the branch name is if we >> > end up with different branch names chosen by each project. There is >> > value in the fact that essentially every project uses the same >> > branch name for their latest development branch, as it gives end >> > users consistent expectations. >> > >> > I'm in favour of changing the branch name, but my inclination is >> > to wait and see a little longer, in order to identify what the >> > new defacto standard ends up being. "main" is a good bet as a new >> > standard, but it would be nice to see it "in action". >> > >> > I'd be looking for two possible signs >> > >> > Whether the Git maintainers themselves decide to standardize >> > on a new term. >> > >> > What GitHub actually decide upon & roll out. >> > >> > Either of those two decisions will set a defacto standard across a >> > vast number of projects, and thus it will be beneficial to have >> > alignme
