From: Dexuan Cui decui@microsoft.com Sent: Friday, November 1, 2024 1:27 PM
From: Michael Kelley mhklinux@outlook.com Sent: Thursday, October 31, 2024 6:39 PM
From: Michael Kelley mhklinux@outlook.com Sent: Wednesday, October 30, 2024 5:12 PM [...] What do you think about this (compile tested only), which splits the "init" function into two parts for devices that have char devs? I'm trying to avoid adding yet another synchronization point by just doing the init operations in the right order -- i.e., don't create the user space /dev entry until the VMBus channel is ready.
Michael
Thanks, I think this works! This is a better fix.
Michael, will you post a formal patch or want me to do it? Either works for me.
I can do it. You probably have more pressing issues to keep you busy .... :-)
- if (srv->util_init_transport) {
ret = srv->util_init_transport();if (ret) {ret = -ENODEV;IMO we don't need the line above, since the 'ret' from srv->util_init_transport() is already a standard error code.
I was just now looking at call_driver_probe(), and it behaves slightly differently for ENODEV and ENXIO vs. other error codes. ENODEV and ENXIO don't output a message to the console unless debugging is enabled, while other error codes always output a message to the console. Forcing the error to ENODEV has been there since the util_probe() code came out of staging in year 2011. But I don't really have a preference either way.
util_probe() is called by vmbus_probe(), which uses pr_err() to print the 'ret'. If the 'ret' is forced to ENODEV, the message in vmbus_probe() may be a little misleading since the real error code is hidden, especially when srv->util_init_transport() doesn't print any error message.
vmbus_probe() is called by call_driver_probe. I guess originally KY wanted to use ENODEV to avoid the extra message for the util devices in call_driver_probe() in non-debugging mode, but the other VSC drivers don't follow this usage.
util_probe() can return a non-ENODEV error code anyway, e.g. ENOMEM and whatever error code from vmbus_open(). IMO, srv->util_init and srv->util_init_transport should not be treated specially.
IMO it's better to not add new code to force the 'ret' to ENODEV, and we'd want to clean up the existing use of ENODEV in util_probe().
Fair enough. I'll do it that way.
Michael