Re: [ANNOUNCE] libblkio v0.1.0 preview release

[Kevin Wolf <kwolf@redhat.com>]

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

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.)

Kevin

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