Am 17.05.2021 um 16:09 hat Stefan Hajnoczi geschrieben: > On Fri, May 14, 2021 at 05:55:13PM +0200, Kevin Wolf wrote: > > Am 13.05.2021 um 11:47 hat Stefan Hajnoczi geschrieben: > > > On Thu, May 06, 2021 at 12:33:24PM +0200, Kevin Wolf wrote: > > > > Am 06.05.2021 um 10:46 hat Stefan Hajnoczi geschrieben: > > > > > What do you think about this: > > > > > > > > > > The blkio instance states are: > > > > > > > > > > created -> attached -> started -> destroyed > > > > > > > > > > It is not possible to go backwards anymore, which simplifies driver > > > > > implementations and it probably won't be needed by applications. > > > > > > > > > > The "initialized" state is renamed to "attached" to make it clearer > > > > > that > > > > > this means the block device has been connected/opened. Also > > > > > "initialized" can be confused with "created". > > > > > > > > > > The corresponding APIs are: > > > > > > > > > > int blkio_create(const char *driver, struct blkio **bp, char > > > > > **errmsg); > > > > > int blkio_attach(struct blkio *bp, char **errmsg); > > > > > int blkio_start(struct blkio *bp, char **errmsg); > > > > > void blkio_destroy(struct blkio **bp); > > > > > > > > > > There is no way to query the state here, but that probably isn't > > > > > necessary since an application setting up the blkio instance must > > > > > already be aware of the state in order to configure it in the first > > > > > place. > > > > > > > > > > One advantage of this approach is that it can support network drivers > > > > > where the attach and start operations can take a long time while > > > > > regular > > > > > property accesses do not block. > > > > > > > > I like this. > > > > > > > > For properties, I think, each property will have a first state in which > > > > it becomes available and then it will be available in all later states, > > > > too. > > > > > > > > Currently, apart from properties that are always read-only, we only have > > > > properties that are rw only in their first state and become read-only in > > > > later states. It might be reasonable to assume that properties will > > > > exist that can be rw in all later states, too. > > > > > > > > In their first state, most properties only store the value into the > > > > config and it's the next state transition that actually makes use of > > > > them. Similarly, reading usually only reads the value from the config. > > > > So these parts can be automatically covered. Usually you would then only > > > > need a custom implementation for property updates after the fact. I > > > > think this could simplify the driver implementations a lot. I'll play > > > > with this a bit more. > > > > > > Hi Kevin, > > > I posted a patch that introduces blkio_connect() and blkio_start(): > > > https://gitlab.com/libblkio/libblkio/-/merge_requests/4 > > > > Assuming that you want review to happen on Gitlab, I added a few > > comments there. > > > > I'm not sure if you saw it, but on Wednesday, I also created a merge > > request for some first changes to reduce the properties boilerplate in > > the iouring module that would otherwise be duplicated for every new > > driver. Not sure if everything is a good idea, but the first patch is > > almost certainly one. > > > > (However, I just realised that the test failure is not the same as on > > main, so I degraded it to a draft now. It also conflicts with your merge > > request. Next thing to learn for me is how to respin a merge request on > > Gitlab... You may want to have a look anyway.) > > Awesome, I will take a look, thanks. I need to tweak my GitLab > notification options :-). > > You can force push to your topic branch to respin the merge request.
Ah, that sounds easy enough. On the other hand, it means I can't work in the branch any more without automatically updating the merge request, so a branch used for a merge request is burned in a way. I should have created a separate branch for this. Looks like I need to familiarise myself more with the Gitlab process before I can expect it to work well for me. :-) Kevin
signature.asc
Description: PGP signature