Re: [ANNOUNCE] libblkio v0.1.0 preview release

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]