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
