* [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.