usr.sbin/bhyve: Fixed DATA_SSET() usage

usr.sbin/bhyve: Fix setting for dynamic loading

usr.sbin/bhyve: addressed comments by trociny and asommers

usr.sbin/bhyve: Make the access decriptor more flexible

usr.sbin/bhyve: remove threadinfo string from block device description

usr.sbin/bhyve: change opague pointer, and rewrote to bb_threadinfo

I guess I addresses a suggestions thusfar.

usr.bin/bhyve: implement code improvements

@trociny
BTW: I'm running my tests like

bhyve-rbd -H -P -A -c 4 -m 2G -l com1,/dev/nmdm1213A -s 0,hostbridge -s 1,lpc -s 2,virtio-net,tap1213 -s 3,ahci-hd,file:/dev/ggate0 -s 4,ahci-hd,/dev/ggate1 FBSD1213

So we are already running of Ceph disks, be it in an odd way.

usr.sbin/bhyve: Make the legacy case operational

usr.sbin/bhyve: Update the backend selection code

usr.sbin/bhyve: Added possible scheme to the man page

usr.sbin/bhyve: Add bb_sche to a backend to specify which backend to use

usr.sbin/bhyve: Addressed comments from @ryan_freqlabs.com

In D23600#519013, @wjw_digiware.nl wrote:

In D23600#519008, @trociny wrote:

In D23600#518961, @wjw_digiware.nl wrote:

Took a while for it to run thru poudriere, but it seems to build just fine....

Willem, just make sure it is clear. By default the package is still built without rbd. You need to set RBD option if you want it to be built with rbd support.

Ah, oke.
I'll have to add a config file then.

Will run again. Should go faster now, since all the other requirements are build.

In D23010#519020, @trociny wrote:

Ah, Willem, this week we have SUSE Hack Week, and I was not aware that you had already been working on rbd driver for bhyve, and picked this as my Hack Week project. And just today accidentally (after your comment to my qemu review) I noticed your review request. I already have some working code [1]. It also adds an abstraction layer in a way similar to yours and has a working driver. It still needs some work: right now librados and librbd from ports are just linked to bhyve, which is not acceptable for upstream, I think we need some solution to try dynamically load the libraries (or even rbd driver) at run time. Anyway I already tried it and it looks like work.

So it looks like unfortunately we did duplicate work. But I am glad you are working on it and would be happy if your version goes upstream, as you started to work on it early. You could look at my version for some ideas though. As it already has rbd driver it might be clearer for reviewers what is the goal of adding this abstraction.

[1] https://github.com/freebsd/freebsd/compare/master...trociny:bhyve-rbd

In D23600#519008, @trociny wrote:

In D23600#518961, @wjw_digiware.nl wrote:

Took a while for it to run thru poudriere, but it seems to build just fine....

Willem, just make sure it is clear. By default the package is still built without rbd. You need to set RBD option if you want it to be built with rbd support.

Took a while for it to run thru poudriere, but it seems to build just fine....

===>  Deinstalling for qemu
===>   Deinstalling qemu-4.1.1_1
Updating database digests format: .......... done
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

bhyve/blocklocal: do external refence to init() and cleanup()

Reversed the way the backend selector is integrated in blockif.
Now every blockif_ctxt is extended with a reference to a backend provider.

Remove struct blockif_ctxt *bc from struct pci_vtblk_softc.
If one needs block device info, you can get it thru the backend-descriptior

Remove bsdinstall diffs that got in this set by accident.

Addresses the style remarks

After I saw remarks about D10335: VirtFS/9p filesystem passthrough support (virtio-9p)​
I wonder where it exactly goes into in the IO-stack.
So is this below anywhere near the right place?

In D23010#511121, @aleksandr.fedorov_itglobal.com wrote:

I think this patch is the right direction. Now it’s really very difficult to add a storage backend other than file-like operations.

In D23010#510564, @marcel wrote:

In D23010#510338, @wjw_digiware.nl wrote:

Having that said, my code is a much more simple aproach in just trying to abstract the block-interface.

For the most part the abstraction shows up as a search-and-replace change, which has its advantages for sure. For me, the immediate question is: what exactly is being abstracted that needed abstracting?
I'm not saying this is a bad change, but I'm saying that comparing it to what libvdsk aims to achieve is doing a huge disfavor to libvdsk :-)

In D23010#510274, @araujo wrote:

Have you ever take a look at: https://github.com/xcllnt/libvdsk
It seemed to me a better idea than what are you trying to achieve here, and there, there is an experimental implementation of qcow2.

I'm much more in favor of libvdsk than this implementation proposed here.

In D23010#509853, @ryan_freqlabs.com wrote:

I have not inspected the code in depth, but there are a number of style violations that jump out at a glance. Fixing these various nits will make the changes easier to read for reviewers. Rather than clutter up the diff I'll just mention the key points:

• Several files appear to have been edited with 4-space indentation settings rather than hard tabs, in contrast with the surrounding code. The different whitespace is confusing/frustrating.
• A bunch of added functions in block_if.c should have a newline after the function return type, rather than a bunch of horizontal space.

See style(9) as a more detailed guide, but in general matching the style of surrounding code is most desirable.

fixed.
Both Igor and mandoc seem to be happy now.

bsdinstall.8: 2e update formating

bsdinstall.8: fixed formating

In D21815#477381, @lwhsu wrote:

pkg-plist seems to need updating: https://gist.github.com/1009408f7a1427f6543b5174acb4ba7b

Update pkg-plist with new dashboard files.

In D21815#477381, @lwhsu wrote:

pkg-plist seems to need updating: https://gist.github.com/1009408f7a1427f6543b5174acb4ba7b

Put .if conditional in the correct block.

This will run under poudriere as well.

@lwhsu

In D21815#476802, @wjw_digiware.nl wrote:

fixing building on 12.0, which has Clang 6.0 adn that version
of the compiler does not work with the versioning used by ceph.

fix leftover space at EoL

Undo debuging in Mk/Uses/cmake.mk

fixing building on 12.0, which has Clang 6.0 adn that version
of the compiler does not work with the versioning used by ceph.

In D21815#476751, @wjw_digiware.nl wrote:

Yup, I have the same problem on my 12.0 poudriere.....
That will take some time to figure out...

Yup, I have the same problem on my 12.0 poudriere.....
That will take some time to figure out...

In D21815#476628, @wjw_digiware.nl wrote:

In D21815#476620, @lwhsu wrote:

It seems not passing poudriere cleanly: https://gist.github.com/6a204afe88fc4531bc9f1b0614bdbb10

Can you help check this?

I had a lot of trouble in getting poudriere to do its thing as well.
Lots of changes in all kinds of tools, buildsystem and ceph code.
So lots of locations to err.
Will take a look at the log.

In D21815#476620, @lwhsu wrote:

It seems not passing poudriere cleanly: https://gist.github.com/6a204afe88fc4531bc9f1b0614bdbb10

Can you help check this?

In D21815#476211, @lwhsu wrote:

Just be curious, we already have net/ceph12 and net/ceph13 in the ports tree. Will we retire the old versions?

In D14590#473178, @lwhsu wrote:

In D14590#473177, @wjw_digiware.nl wrote:

Nope, I'm not sure why this was not closed when it got commited.

Perhaps some system internal issues. Please close this by hand, thanks!

In D14590#473165, @lwhsu wrote:

net/ceph is 12.2.7 now. Do we still need have this open?

@mat I guess somebody had to the first... 8-)

Start using PY_BOOST instead of explicit referencing the libs

Needed to update the Git hash going with this release.
It is include in error reporting by ceph

In D13699#286672, @jbeich wrote:

In D13699#286484, @wjw_digiware.nl wrote:

1. I need LLD because otherwise one off the executables does not link. Seems to be a size limitation in the regular ld And after discussion with Ed Maste this was the solution that worked. Not sure how that impacts on 11.x. But my Ceph testruns do seem to work.

I can't reproduce. Even without -fuse-ld= and -B${LOCALBASE}/bin ceph-12.2.2 builds fine: boost-libs-1.65.1_1 (11.1 amd64, 12.0 amd64), boost-libs-1.66.0 (11.1 amd64, 12.0 amd64). Can you provide more details e.g., poudriere log?

@jbeich
Could you approve once again, fixed the way the versioning was done.
This makes more sense IMHO

Reorder to make portlint happy

Cleanup of versionstring in package.
And remove the v from v12.2.2

In D13699#286526, @jbeich wrote:

Is it OK to land before Boost 1.66.0 for 2018Q1 users given Ceph 12.2.2 builds fine against Boost 1.65.1? Or did you disable some features (e.g., WITH_RADOSGW_BEAST_FRONTEND) for the sake of Boost 1.66?

Remove verbose output during linking
leftover from getting lld to work

Move cython usage to USE_PYTHON

1. I need LLD because otherwise one off the executables does not link. Seems to be a size limitation in the regular ld And after discussion with Ed Maste this was the solution that worked. Not sure how that impacts on 11.x. But my Ceph testruns do seem to work.
2. I tried all kinds of incantations to get LLD to work, and this was the one that actually worked. It was painfull since it needs a poudriere rerun for every attempt. And even with ccache Ceph is big to build.
3. Not really sure on how to verify that. But I would expect LDFLAGS to end up in LINK_FLAGS

Reduce diffs on white spaces and trivia

Accidently include the Boost 1.66 updates.
Try to remove them from this PR

Since my port was change in between by ports-managers
there were some unneeded changes.
So reduce the difference between version.

@mat
I understand, and will ask on the ports-list if somebody wants to do the honnurs.

@mat @mmokhi
Any particular reason why this cannot move forward.
I'm having the first official release of net/ceph in the pipe.
Just waiting for it to be release by the Ceph-developers.
Would be nice if that one have not the same discussion we have here.

In D9584#210073, @feld wrote:

Looks good now, builds cleanly.

net/ceph-devel: Update the submission

Going to fix that

@feld
Hi Mark,

net/ceph-devel: integrating mmokhi patches.

net/ceph-devel: integrating mmokhi patches.

In D9584#208085, @mmokhi wrote:

Hmm, yeah.
@feld I'd suggest to test the patch that I attached on the PR (or @wjw_digiware.nl can update diffs here :D)
I forgot to state this problem on PR (but it's fixed on attached patch) that recently things are added to GID/UID files right before our entry, which makes this patch fail.

@feld
Not sure why it would fail.
Other than that @mmokhi 's changes are perhaps not in this review.
But that should not prevent you from importing the basic files.
But it seems to confilect on the ceph entries in GUIDs and UIDs.

In D9584#206275, @mat wrote:

In D9584#205334, @wjw_digiware.nl wrote:

@mat
Sorry to nag, but is there a reason this does not move forward?

Well, this, here, is a code review tool, we review code, and make it better, and then commit it. For non committers, I still think that once everything is ok, a PR should be openned with the final patch so that it is added to the tree. I don't have the spare time to test-build it and commit it.

@mat
Sorry to nag, but is there a reason this does not move forward?

@mat
Is there anything else I need to do?

net/ceph-devel: Deleted auto file etc/rc.d/ceph

net/ceph-devel: sorted pkg-plist