24/01/2018 16:24, Yuanhan Liu: > On Tue, Jan 23, 2018 at 05:08:16PM +0100, Gaëtan Rivet wrote: > > Drivers answers to a specific API (ethdev, cryptodev, ...), to create > > standardized objects in response to parameters that are given to them > > for init. I think matching properties should be restricted to higher > > classes (bus, eth/crypto), > > That's also what I thought. But I'm okay to have "driver" category > included for matching. I just don't really see a good example for that. > > > while the driver class should be left > > free-form and to the responsibility of the PMD itself (while having the > > proper libraries for helping parsing safely, thus driving developpers > > toward similar syntaxes, while not forcing them in those). > > I agree. The drv args are parsed by the drivers after all. It's hard to > have a good parser for all. I also don't know why we have to force them > to use "key=value" pairs. > > I even see some drawbacks from the forcement: > > - some PMDs already use none key/value format. Forcing them breaks more. > If the "-w" "--vdev" compatibility is kept", nothing will be broken > from the user point of view. However, if "key=value" pair is going to > be used, user have to do some changes. > > - Some "value" might have to use the nested "=". Handling the nested pairs > introduces more complexity. > > - sometimes, it's simple without an assignment. For example, it could be > "driver=vhost-pmd,...,client" to let the vhost PMD acts as the client > mode. > > Both Linux kernel and QEMU don't force the "key=value" pair usage, I don't > see any good reason why we have to do that.
OK
