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.
--yliu
