search for: add_wildcard

...like: "mdev:cN" */ > >> +static int do_mdev_entry(const char *filename, void *symval, char *alias) > >> +{ > >> + DEF_FIELD(symval, mdev_class_id, id); > >> + > >> + sprintf(alias, "mdev:c%02X", id); > > A lot of entries call add_wildcard() here, should we? Sorry for the > > basic questions, I haven't played in this code. Thanks, > > > It's really good question. My understanding is we won't have a module > that can deal with all kinds of classes like CLASS_ID_ANY. So there's > probably no...

...r *alias) > return 1; > } > > +/* looks like: "mdev:cN" */ > +static int do_mdev_entry(const char *filename, void *symval, char *alias) > +{ > + DEF_FIELD(symval, mdev_class_id, id); > + > + sprintf(alias, "mdev:c%02X", id); A lot of entries call add_wildcard() here, should we? Sorry for the basic questions, I haven't played in this code. Thanks, Alex > + return 1; > +} > + > /* Does namelen bytes of name exactly match the symbol? */ > static bool sym_is(const char *name, unsigned namelen, const char *symbol) > { > @@ -14...

...r *alias) > return 1; > } > > +/* looks like: "mdev:cN" */ > +static int do_mdev_entry(const char *filename, void *symval, char *alias) > +{ > + DEF_FIELD(symval, mdev_class_id, id); > + > + sprintf(alias, "mdev:c%02X", id); A lot of entries call add_wildcard() here, should we? Sorry for the basic questions, I haven't played in this code. Thanks, Alex > + return 1; > +} > + > /* Does namelen bytes of name exactly match the symbol? */ > static bool sym_is(const char *name, unsigned namelen, const char *symbol) > { > @@ -14...

...@@ static int do_wmi_entry(const char *filename, void *symval, char *alias) return 1; } +/* looks like: "mdev:cN" */ +static int do_mdev_entry(const char *filename, void *symval, char *alias) +{ + DEF_FIELD(symval, mdev_class_id, id); + + sprintf(alias, "mdev:c%02X", id); + add_wildcard(alias); + return 1; +} + /* Does namelen bytes of name exactly match the symbol? */ static bool sym_is(const char *name, unsigned namelen, const char *symbol) { @@ -1407,6 +1417,7 @@ static const struct devtable devtable[] = { {"typec", SIZE_typec_device_id, do_typec_entry}, {&quot...

...} >> >> +/* looks like: "mdev:cN" */ >> +static int do_mdev_entry(const char *filename, void *symval, char *alias) >> +{ >> + DEF_FIELD(symval, mdev_class_id, id); >> + >> + sprintf(alias, "mdev:c%02X", id); > A lot of entries call add_wildcard() here, should we? Sorry for the > basic questions, I haven't played in this code. Thanks, It's really good question. My understanding is we won't have a module that can deal with all kinds of classes like CLASS_ID_ANY. So there's probably no need for the wildcard. Thanks...

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver

Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver