Re: [Nbd] Plugin inteface vs library

[Wouter Verhelst <w@...112...>]

On Sun, Sep 05, 2010 at 10:51:14PM +0200, Laurent Vivier wrote:
> Le samedi 04 septembre 2010 à 14:30 +0200, Wouter Verhelst a écrit :
> > I would think that such things could be useful for what you're trying to
> > do, as well; but since I don't know what your plans are, that requires
> > me to guess. Can you comment on what your goals are?
> 
> My first goal is to make some code cleanup, as I think existing code is
> hard to read (and understand).

Aha.

I must say that putting code in different files has been a bit of a
background, low-priority TODO item for me. I just haven't gotten around
to it yet, so, erm, thanks :-)

> I think the best way to do that is to put
> all the core code of NDB in a library (for moment it is an archive
> libnbd.a) as it has already been done in qemu to write a server serving
> all qemu disk images (qcow2, raw, ...) or to attach an NBD disk as an
> emulated disk ("qemu -hda nbd:localhost"):
> 
> http://git.qemu.org/qemu.git/tree/nbd.c		(as could be the libnbd)
> http://git.qemu.org/qemu.git/tree/qemu-nbd.c	(as could be the nbd-server)
> http://git.qemu.org/qemu.git/tree/block/nbd.c	(as could be the nbd-client)

Right. I was aware of the nbd implementation in qemu, though not of the
emulated disk option (that is, I thought it could only do the server
side).

> I'm not sure I understand how you are modifying nbd-server, but it seems
> you are trying to add functionalities to it whereas I'm trying to remove
> existing ones (to put them in a library)[1]. As it is two radically
> different approaches, I think both of them can be implemented: plugins
> allow nbd-server to read files like qemu-nbd does (qcow2, raw, ...)
> whereas library allow programs like qemu to act like an nbd-server or an
> nbd-client.

Of course, that wasn't my point. It's just that if we're going to be
doing a library, we might want to design the interface so that library
users can also use the plugins, if they want -- or they could
'implement' a plugin in their main executable (really just set a bunch
of function pointers to internal functions). Or something yet entirely
different that I haven't thought about.

I had been planning to make the configuration file extendable from
plugins, by allowing them to add to the 'gp' and 'lp' arrays in some
way. I might need to revisit that if we're going to make it any useful
for library users.

> But if we focus only on code readability, IMHO, to have a library is a
> good thing.
> 
> What is your opinion ?
> I don't like to do useless work (nights are too short).

Sure.

I'm not entirely sure whether I think doing a library is a good idea. On
the one hand, if there's a library, I think it should be a shared
library rather than a static one; not just because Debian policy
strongly recommends it, but also because there are serious advantages to
it. On the other hand, that would increase the maintenance burden
significantly (shared libraries are a pain to maintain correctly), and
I'm not sure whether I wish to do that.

But I do see the advantage of exporting the 'useful' bits to other
applications, even if that'd only be used by, say, the tester client.
There's no reason why anyone would need to reimplement the important
bits of nbd if all they want to do is to export something that isn't
directly a file.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html