Module naming

[cfcs]

The modules are currently named like

• Block
• Block_request
• Blkback
• Blkproto
• Blkfront
• Device_state

This is inconsistent with the Mirage_block_* modules exposed in mirage-block,
and it also differs from the pattern of for example mirage-block-ramdisk which exposes Mirage_block_ramdisk (that one also exposes Ramdisk, but oh well).

[yomimono]

We could probably stand to rethink what's exposed by mirage-block-xen.

AFAIK there are no external users of the .back sublibrary, where Blkback and Block_request are, nor Blkproto and Device_number in mirage-block-xen. The .front sublibrary is used by mirage, but Blkfront isn't directly referenced in the main.ml generated by mirage (rather Block), so that naming could change also (perhaps just rename Blkfront to Block).

@djs55 and @avsm for fact-checking on users of mirage-block-xen ; opam list --depends-on mirage-block-xen gets nothing, but I may overlooking something.

[avsm]

I think this is right -- there are very few external users since the uses are various xapi unikernels (which can be adapted if needed). I'll take a look at wrapping this library up entirely when I refresh it to remove dependency on the OS module.

[djs55]

I think the only user of the backend is xen-disk: https://github.com/djs55/xen-disk/blob/3939f642824812269ef8112ed7d040dc34b97f21/_oasis#L16 . Perhaps `Blkback` and `Block_request` could be merged and exposed as Mirage_block_xen.Backend? Renaming `Blkfront` to `Block` sounds fine. I guess this would be `Mirage_block_xen.Block` to avoid polluting the global namespace (and allow an app to have multiple `Block` implementations linked at once)? My plan / aspiration (of many years, still not done) is to refactor this code to be more like ocaml-vchan, where everything is functorised over shared memory and events, so we can have some nice unit tests where a frontend talks to a backend. No need for us to wait for that work before doing some tidying up though :)

…

On Mon, Jan 14, 2019 at 7:15 PM Anil Madhavapeddy ***@***.***> wrote: I think this is right -- there are very few external users since the uses are various xapi unikernels (which can be adapted if needed). I'll take a look at wrapping this library up entirely when I refresh it to remove dependency on the OS module. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMHuoh_K3TO5bQNzlv0I3cUyxGDw_Wkks5vDNc-gaJpZM4Q0waS> .

[cfcs]

I think modules in libraries should try not to pick names like Block that applications might reasonably want to use, at least while it's still a pain to have clashing names (until we get some kind of namespacing), but I agree with the rest of your comments @yomimono @avsm @djs55 :) -- IIRC what made me open this issue was that I had trouble compiling my unikernel because I had my own module also called Block, which prompted me to look for the other one :)