From: Cornelia Huck <cohuck@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
virtio@lists.oasis-open.org, virtio-comment@lists.oasis-open.org
Subject: [virtio] Re: [virtio-comment] allocating device IDs without a vote
Date: Fri, 30 Oct 2020 13:16:45 +0100 [thread overview]
Message-ID: <20201030131645.3f1ce61e.cohuck@redhat.com> (raw)
In-Reply-To: <2b6a81de-089d-aaad-7c74-78b6f534164e@siemens.com>
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
next prev parent reply other threads:[~2020-10-30 12:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-10-30 13:51 ` Mihai Carabas
2020-10-30 14:38 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201030131645.3f1ce61e.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=mst@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.