search for: sym_i

...+ 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) > { > @@ -1407,6 +1416,7 @@ static const struct devtable devtable[] = { > {"typec", SIZE_typec_device_id, do_typec_entry}, > {"tee", SIZE_tee_client_device_id, do_tee_entry}, > {"wmi", SIZE_...

...+ 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) > { > @@ -1407,6 +1416,7 @@ static const struct devtable devtable[] = { > {"typec", SIZE_typec_device_id, do_typec_entry}, > {"tee", SIZE_tee_client_device_id, do_tee_entry}, > {"wmi", SIZE_...

...} +/* 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); + 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 +1416,7 @@ static const struct devtable devtable[] = { {"typec", SIZE_typec_device_id, do_typec_entry}, {"tee", SIZE_tee_client_device_id, do_tee_entry}, {"wmi", SIZE_wmi_device_id, do_wmi_ent...

...uot;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}, {"tee", SIZE_tee_client_device_id, do_tee_entry}, {"wmi", SIZE_wmi_device_id, do_wmi_ent...

...n'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 > > Alex > >> + 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 +1416,7 @@ static const struct devtable devtable[] = { >> {"typec", SIZE_typec_device_id, do_typec_entry}, >> {"tee", SIZE_tee_client_device_id, do_tee_entry}, >>...

Further cleanup of the hv drivers. 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across the board and use standard Linux error codes. 3) General cleanup Regards, K. Y

Further cleanup of the hv drivers. 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across the board and use standard Linux error codes. 3) General cleanup Regards, K. Y

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

Further cleanup of the hv drivers. Back in June I had sent two patch sets to address these issues. I have addressed the comments I got from the community on my earlier patches here: 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across

Further cleanup of the hv drivers. Back in June I had sent two patch sets to address these issues. I have addressed the comments I got from the community on my earlier patches here: 1) Implement code for autoloading the vmbus drivers without using PCI or DMI signatures. I have implemented this based on Greg's feedback on my earlier implementation. 2) Cleanup error handling across

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 hardware 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 to

Hi all: There are hardware 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 to

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