Re: [ANNOUNCE] libblkio v0.1.0 preview release

[Stefan Hajnoczi]

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.

Stefan

signature.asc
Description: PGP signature