* [virtio] allocating device IDs without a vote @ 2020-10-30 10:15 Michael S. Tsirkin 2020-10-30 10:23 ` [virtio-comment] " Dr. David Alan Gilbert 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2020-10-30 10:15 UTC (permalink / raw) To: virtio; +Cc: virtio-comment At the Virtio BoF at the virtual KVM forum, 2020, a recurring theme was the difficulty contributors face in obtaining device IDs for new devices. As allocating a new ID is a technicality, and can not break existing devices, it does not sound too bad to skip a voting step in that process. I'd like to hear TC's take on such an idea. This would be similar to the existing standing rule: Minor cleanups, including editorial formatting changes, spelling and typo fixes can be committed directly into git for approval as part of the next specification approval ballot. -- MST --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] allocating device IDs without a vote 2020-10-30 10:15 [virtio] allocating device IDs without a vote Michael S. Tsirkin @ 2020-10-30 10:23 ` Dr. David Alan Gilbert 2020-10-30 10:30 ` [virtio] " Jan Kiszka 0 siblings, 1 reply; 6+ messages in thread From: Dr. David Alan Gilbert @ 2020-10-30 10:23 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: virtio, virtio-comment * Michael S. Tsirkin (mst@redhat.com) wrote: > At the Virtio BoF at the virtual KVM forum, 2020, a recurring theme was > the difficulty contributors face in obtaining device IDs for new > devices. As allocating a new ID is a technicality, and can not break > existing devices, it does not sound too bad to skip a voting step in > that process. It would seem reasonable to define what the expectations, if any are, about the use of those IDs: Is it expected that the allocator of such an ID would eventually end a request to merge a spec for the device, or are they free not to? If merging is expected, then is it acceptable to recycle IDs that have not been defined after n-Years. Dave > I'd like to hear TC's take on such an idea. > > This would be similar to the existing standing rule: > > Minor cleanups, including editorial formatting changes, spelling > and typo fixes can be committed directly into git for approval as part > of the next specification approval ballot. > > -- > MST > > > This publicly archived list offers a means to provide input to the > OASIS Virtual I/O Device (VIRTIO) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org > List help: virtio-comment-help@lists.oasis-open.org > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists > Committee: https://www.oasis-open.org/committees/virtio/ > Join OASIS: https://www.oasis-open.org/join/ > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* [virtio] Re: [virtio-comment] allocating device IDs without a vote 2020-10-30 10:23 ` [virtio-comment] " Dr. David Alan Gilbert @ 2020-10-30 10:30 ` Jan Kiszka 2020-10-30 12:16 ` Cornelia Huck 0 siblings, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2020-10-30 10:30 UTC (permalink / raw) To: Dr. David Alan Gilbert, Michael S. Tsirkin; +Cc: virtio, virtio-comment On 30.10.20 11:23, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (mst@redhat.com) wrote: >> At the Virtio BoF at the virtual KVM forum, 2020, a recurring theme was >> the difficulty contributors face in obtaining device IDs for new >> devices. As allocating a new ID is a technicality, and can not break >> existing devices, it does not sound too bad to skip a voting step in >> that process. > > It would seem reasonable to define what the expectations, if any are, > about the use of those IDs: > > Is it expected that the allocator of such an ID would eventually > end a request to merge a spec for the device, or are they free > not to? > > If merging is expected, then is it acceptable to recycle IDs that have > not been defined after n-Years. > Lowering the barrier for grabbing IDs too much and not establishing a garbage collection mechanism can eventually shoot back, IMHO. Jan > Dave > > >> I'd like to hear TC's take on such an idea. >> >> This would be similar to the existing standing rule: >> >> Minor cleanups, including editorial formatting changes, spelling >> and typo fixes can be committed directly into git for approval as part >> of the next specification approval ballot. >> >> -- >> MST >> >> >> This publicly archived list offers a means to provide input to the >> OASIS Virtual I/O Device (VIRTIO) TC. >> >> In order to verify user consent to the Feedback License terms and >> to minimize spam in the list archive, subscription is required >> before posting. >> >> Subscribe: virtio-comment-subscribe@lists.oasis-open.org >> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org >> List help: virtio-comment-help@lists.oasis-open.org >> List archive: https://lists.oasis-open.org/archives/virtio-comment/ >> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf >> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists >> Committee: https://www.oasis-open.org/committees/virtio/ >> Join OASIS: https://www.oasis-open.org/join/ >> -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ^ permalink raw reply [flat|nested] 6+ messages in thread
* [virtio] Re: [virtio-comment] allocating device IDs without a vote 2020-10-30 10:30 ` [virtio] " Jan Kiszka @ 2020-10-30 12:16 ` Cornelia Huck 2020-10-30 13:51 ` Mihai Carabas 2020-10-30 14:38 ` Stefan Hajnoczi 0 siblings, 2 replies; 6+ messages in thread From: Cornelia Huck @ 2020-10-30 12:16 UTC (permalink / raw) To: Jan Kiszka Cc: Dr. David Alan Gilbert, Michael S. Tsirkin, virtio, virtio-comment On Fri, 30 Oct 2020 11:30:09 +0100 Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 30.10.20 11:23, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (mst@redhat.com) wrote: > >> At the Virtio BoF at the virtual KVM forum, 2020, a recurring theme was > >> the difficulty contributors face in obtaining device IDs for new > >> devices. As allocating a new ID is a technicality, and can not break > >> existing devices, it does not sound too bad to skip a voting step in > >> that process. > > > > It would seem reasonable to define what the expectations, if any are, > > about the use of those IDs: > > > > Is it expected that the allocator of such an ID would eventually > > end a request to merge a spec for the device, or are they free > > not to? > > > > If merging is expected, then is it acceptable to recycle IDs that have > > not been defined after n-Years. > > > > Lowering the barrier for grabbing IDs too much and not establishing a > garbage collection mechanism can eventually shoot back, IMHO. Maybe we really need two things: - a "private" range, that anyone can use for playing etc. - an easy way to request an ID, combined with some kind of garbage collection We currently do have some IDs without a spec, but we really need to keep some of them reserved, as there are already (sometimes legacy) devices out there. Perhaps there needs to be some kind of annotation? If you reserve an ID via the quick mechanism, it gets a "reserved until YYYY-MM-DD", and that tag gets removed when a proper spec is merged? For "in-the-wild-do-not-reuse" IDs, we'd still require a vote, as the default should be to have a proper spec if you want something outside of the private namespace. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio] Re: [virtio-comment] allocating device IDs without a vote 2020-10-30 12:16 ` Cornelia Huck @ 2020-10-30 13:51 ` Mihai Carabas 2020-10-30 14:38 ` Stefan Hajnoczi 1 sibling, 0 replies; 6+ messages in thread From: Mihai Carabas @ 2020-10-30 13:51 UTC (permalink / raw) To: Cornelia Huck, Jan Kiszka Cc: Dr. David Alan Gilbert, Michael S. Tsirkin, virtio, virtio-comment On 10/30/2020 2:16 PM, Cornelia Huck wrote: > On Fri, 30 Oct 2020 11:30:09 +0100 > Jan Kiszka <jan.kiszka@siemens.com> wrote: > >> On 30.10.20 11:23, Dr. David Alan Gilbert wrote: >>> * Michael S. Tsirkin (mst@redhat.com) wrote: >>>> At the Virtio BoF at the virtual KVM forum, 2020, a recurring theme was >>>> the difficulty contributors face in obtaining device IDs for new >>>> devices. As allocating a new ID is a technicality, and can not break >>>> existing devices, it does not sound too bad to skip a voting step in >>>> that process. >>> >>> It would seem reasonable to define what the expectations, if any are, >>> about the use of those IDs: >>> >>> Is it expected that the allocator of such an ID would eventually >>> end a request to merge a spec for the device, or are they free >>> not to? >>> >>> If merging is expected, then is it acceptable to recycle IDs that have >>> not been defined after n-Years. >>> >> >> Lowering the barrier for grabbing IDs too much and not establishing a >> garbage collection mechanism can eventually shoot back, IMHO. > > Maybe we really need two things: > > - a "private" range, that anyone can use for playing etc. > - an easy way to request an ID, combined with some kind of garbage > collection > > We currently do have some IDs without a spec, but we really need to > keep some of them reserved, as there are already (sometimes legacy) > devices out there. > > Perhaps there needs to be some kind of annotation? If you reserve an ID > via the quick mechanism, it gets a "reserved until YYYY-MM-DD", and > that tag gets removed when a proper spec is merged? For > "in-the-wild-do-not-reuse" IDs, we'd still require a vote, as the > default should be to have a proper spec if you want something outside > of the private namespace. I agree with Cornelia and Jan. Thank you, Mihai Carabas --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ^ permalink raw reply [flat|nested] 6+ messages in thread
* [virtio] Re: [virtio-comment] allocating device IDs without a vote 2020-10-30 12:16 ` Cornelia Huck 2020-10-30 13:51 ` Mihai Carabas @ 2020-10-30 14:38 ` Stefan Hajnoczi 1 sibling, 0 replies; 6+ messages in thread From: Stefan Hajnoczi @ 2020-10-30 14:38 UTC (permalink / raw) To: Cornelia Huck Cc: Jan Kiszka, Dr. David Alan Gilbert, Michael S. Tsirkin, virtio, virtio-comment [-- Attachment #1: Type: text/plain, Size: 1238 bytes --] On Fri, Oct 30, 2020 at 01:16:45PM +0100, Cornelia Huck wrote: Let's clarify whether it is acceptable to keep the device without a spec indefinitely. I am starting to get the feeling people would like to define one-off VIRTIO devices that are unlikely to be implemented elsewhere. As VIRTIO expands we may find it acceptable to allow these use cases, but expectations should be clear: 1. VIRTIO spec features won't be added for out-of-tree devices. The user needs to be in the spec so that the design can be reviewed. 2. Out-of-tree devices that violate the VIRTIO device model may cease to work or be impossible to implement as the VIRTIO spec evolves. > Perhaps there needs to be some kind of annotation? If you reserve an ID > via the quick mechanism, it gets a "reserved until YYYY-MM-DD", and > that tag gets removed when a proper spec is merged? For > "in-the-wild-do-not-reuse" IDs, we'd still require a vote, as the > default should be to have a proper spec if you want something outside > of the private namespace. I'm not sure revoking an ID is realistic in the case where the owner refuses to upstream a spec but is shipping devices. The upstream device that reused the ID will suffer when collisions occur. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-30 14:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-30 10:15 [virtio] allocating device IDs without a vote Michael S. Tsirkin 2020-10-30 10:23 ` [virtio-comment] " Dr. David Alan Gilbert 2020-10-30 10:30 ` [virtio] " Jan Kiszka 2020-10-30 12:16 ` Cornelia Huck 2020-10-30 13:51 ` Mihai Carabas 2020-10-30 14:38 ` Stefan Hajnoczi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.