OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] allocating device IDs without a vote


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]