[dpdk-dev] [PATCH v1 1/5] rawdev: introduce raw device library support

[Trahe, Fiona]

Hi Shreyansh,

/// snip ///
> > [Fiona] Yes. I'm probably overcomplicating it.
> > I was considering scanned devices and e.g. a case where 2 PMDs inadvertently pick the same name.
> > One idea would be each driver would register a type string with the lib layer and
> > all its device names must start with this, thus ensuring that each device name is unique.
> > With the vdev devices the application can ensure device names are unique.
> > A driver would not be allowed to use a name starting with a string which another PMD had already
> registered.
> >
> > This would allow looser coupling between the applications and the PMDs, as applications
> > would not need to know the exact name format of device name, just know the type it wants to use
> > and search for all devices with names starting with that string.
> > But I'm probably anticipating issues which wouldn't happen in real world applications.
> > i.e. though there may be many PMDs and applications in the dpdk codebase using this lib in future,
> > it's likely only a small number will be compiled into any build so such name clashes are unlikely to occur.
> > And the applications must be tightly coupled with the PMD anyway to make use of the device, so
> > that's probably not a concern either.
> I agree with the last line that applications have to be tightly coupled
> with PMD in this case. That defines (or prevents defining) a lot of
> semantics.
> 
> While creating the patches, even I was thinking of standardizing the
> naming (taking hint from some of Gaetan's work on devargs) but I
> couldn't think of a policy which can be enforced only by the rawlib.
> 
> I concur with you that conflicting naming in a real world scenario is
> theoretically possible, irrespective of how rare it might be.
> 
> I suggest that we continue as is and expand this in future when we have
> more clarity or even some real-world application samples.
> 
> You have any objections to this?
> 
No, I agree, this is the best approach.

Fiona