[lkml]   [2019]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 0/2] Simplify mtty driver and mdev core
On Wed, 14 Aug 2019 05:54:36 +0000
Parav Pandit <> wrote:

> > > I get that part. I prefer to remove the UUID itself from the structure
> > > and therefore removing this API makes lot more sense?
> >
> > Mdev and support tools around mdev are based on UUIDs because it's defined
> > in the documentation.
> When we introduce newer device naming scheme, it will update the documentation also.
> May be that is the time to move to .rst format too.

You are aware that there are existing tools that expect a uuid naming
scheme, right?

> > I don't think it's as simple as saying "voila, UUID
> > dependencies are removed, users are free to use arbitrary strings". We'd need
> > to create some kind of naming policy, what characters are allows so that we
> > can potentially expand the creation parameters as has been proposed a couple
> > times, how do we deal with collisions and races, and why should we make such
> > a change when a UUID is a perfectly reasonable devices name. Thanks,
> >
> Sure, we should define a policy on device naming to be more relaxed.
> We have enough examples in-kernel.
> Few that I am aware of are netdev (vxlan, macvlan, ipvlan, lot more), rdma etc which has arbitrary device names and ID based device names.
> Collisions and race is already taken care today in the mdev core. Same unique device names continue.

I'm still completely missing a rationale _why_ uuids are supposedly
bad/restricting/etc. We want to uniquely identify a device, across
different types of vendor drivers. An uuid is a unique identifier and
even a well-defined one. Tools (e.g. mdevctl) are relying on it for
mdev devices today.

What is the problem you're trying to solve?

 \ /
  Last update: 2019-08-14 10:26    [W:0.047 / U:28.840 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site