Indentation looks different than in the rest of the file.

!= NULL please to avoid confusion about the type.

This isn't the only place I see this, but I'll just point it out here:
Minor style nit - Values in return statements should be enclosed in parentheses.

return (bc->be->close(bc));

Please prefix the struct members with bb_.

I think it would be a bit simpler to use an opaque pointer for private data.

BTW, in my version I just check optstr for a prefix ending with semicolon (e.g. 'rbd:'), and then use this prefix to find the driver.

@trociny

I think it is beter actually to leave this up to the backends themselfs, this creates more flexibility. And would for example allow for multiple /........ backends. Where if the basic local backend refuses, there could be other backends working on this optstr that can handle the request.

I have not fixed this in files I have not touched.

I can hardly imagine how backends are going to detect if its "their" device, if only they would not rely on some prefix name. And if they would why not to do this in generic way instead of implementing this in every driver?

So, bhyve would look for provided disk name, and if it had "foo:" prefix, it would assume that the driver is "foo", and would try to open the device using this driver (if it had been successfully loaded.

I agree with scheme: suggest, ie file://, rbd://, nbd://, etc. with a fallback to the file backend if no scheme is given. Each backend can register its scheme name and we can directly pick the right one with no ambiguity.

Oops, I meant to remove // from the rest of those before I submit. Anything after the : would be passed to the backend.

Right, and perhaps keep the /...... for legacy defaulting to local store.

@trociny

I guess it would be possible to add a scheme descriptor to the backend struct, and only go with that.
But then still you'd have to call bb_open() to see it the optstr is a valid string and attach the device.

Note, bb_open may return NULL here and you will be dereferencing NULL

What is a point of passing the scheme prefix to the driver? The first step that it would need to do is to trim it. Why not instead always pass to the bb_open optstr without scheme. It is easy to trim it from the optstr that has it -- just increase optstr by the prefix length.

nit: I would call it bb_name and store the backend name without ending ':' ("file", "rbd").

good call

Yeah, that is the other way around .....
Makes it easier here, but a bit more code in the FOR loop

1. Sure, can do
2. that makes the code only more convoluted.

what if optstr contains /file/, so it will require checking if strstr returns start of optstr AND that bb_name != ""
And then we need still to go out and find the ":"
But I'll give it a shot.

Otherwise you would have "a bit mode code" in every driver to parse the prefix.

I am not quite sure I follow. I suggest not to store ':' in the backend name, but sure the ':' should be present in optstr to separate scheme (backend) name from the rests of params. When parsing optstr for the backend name you should look for the first occurrence of ':' character and use the part of the string before ':' as a backend name if all characters there are alphanumeric. And the part of the string after ':' is passed to the backend open function (if you found the backend with such a name).

If you null out the ':' before moving the pointer forward then you can use strcmp below to ensure we get an exact match for the backend name.

*optrest = '\0';
optrest++;

This comment is outdated.

We can break if open fails. There should be only one backend with the given name.

This you will have to fight with @trociny, since he did not like the name scheme.
Note that ATM, bb_threadinfo is not used, since we only use what the parent
inserted. So it is things like `"%d:%d", pi->pi_slot, pi->pi_func that set the threadname.

My point actually was why have both bb_name|prefix and bb_scheme? Why don't just have one param: bb_name, so it is both the thread name and scheme name, whatever. It looks for me perfectly well if one have to specify a device like 'blk-local:/path/to/dev_or_file'