On 6/10/19 8:29 AM, Vladimir Sementsov-Ogievskiy wrote: >> Hmm, and then, include it into BDRVNBDState? I don't remember why didn't do >> it, and now I don't see any reason for it. We store this information anyway >> for the whole life of the driver.. >> >> So, if I'm going to refactor it, I have a question: is there a reason for >> layered BDRVNBDState: >> >> typedef struct BDRVNBDState { >> NBDClientSession client; >> >> /* For nbd_refresh_filename() */ >> SocketAddress *saddr; >> char *export, *tlscredsid; >> } BDRVNBDState; >> >> and use nbd_get_client_session everywhere instead of simple converting void >> *opaque >> to State pointer like in qcow2 for example? >> >> The only reason I can imagine is not to share the whole BDRVNBDState, and >> keep >> things we are using only in nbd.c to be available only in nbd.c.. But I've >> put >> saddr and export to NBDConnection to be used in nbd-client.c anyway. So, I >> think >> it's a good moment to flatten and share BDRVNBDState and drop >> nbd_get_client_session. >> > > And if we are here, what is exact purpose of splitting nbd-client.c from > nbd.c?
I see no strong reasons to keep the separation. If a single large file is easier to maintain than an arbitrary split between two files, I'm open to the idea of a patch that undoes the split. > or need of defining driver callbacks in header file, instead of keeping them > together > with driver struct definition and static (like other block drivers)... > > > And names of these two files always confused me.. nbd.c is nbd client block > driver, and > driver is defined here.. But we have nbd-client.c which defines nbd client > driver too. > And we also have nbd/client.c (OK, this split I understand of course, but it > increases > confusion anyway). I'm also toying with the idea of writing block/nbd.c to utilize the relatively-new libnbd library, to see if there are any differences in behavior by offloading NBD access to a 3rd-party library. But that's further down the road. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature