usr.sbin/bhyve: Fixed DATA_SSET() usage
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 21 2020
Mar 20 2020
usr.sbin/bhyve: Fix setting for dynamic loading
usr.sbin/bhyve: addressed comments by trociny and asommers
Mar 4 2020
usr.sbin/bhyve: Make the access decriptor more flexible
Feb 26 2020
usr.sbin/bhyve: remove threadinfo string from block device description
Feb 25 2020
usr.sbin/bhyve: change opague pointer, and rewrote to bb_threadinfo
I guess I addresses a suggestions thusfar.
usr.bin/bhyve: implement code improvements
Feb 14 2020
@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
Feb 13 2020
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.
Feb 12 2020
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):
Jan 27 2020
bhyve/blocklocal: do external refence to init() and cleanup()
Jan 26 2020
Reversed the way the backend selector is integrated in blockif.
Now every blockif_ctxt is extended with a reference to a backend provider.
Jan 23 2020
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?
Jan 22 2020
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.
Jan 20 2020
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.
Jan 18 2020
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.
Jan 2 2020
Dec 30 2019
fixed.
Both Igor and mandoc seem to be happy now.
bsdinstall.8: 2e update formating
bsdinstall.8: fixed formating
Oct 23 2019
In D21815#477381, @lwhsu wrote:pkg-plist seems to need updating: https://gist.github.com/1009408f7a1427f6543b5174acb4ba7b
Oct 1 2019
Update pkg-plist with new dashboard files.
In D21815#477381, @lwhsu wrote:pkg-plist seems to need updating: https://gist.github.com/1009408f7a1427f6543b5174acb4ba7b
Sep 30 2019
Put .if conditional in the correct block.
This will run under poudriere as well.
Sep 29 2019
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...
Sep 28 2019
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?
Sep 27 2019
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?
Sep 17 2019
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?
Mar 6 2018
@mat I guess somebody had to the first... 8-)
Start using PY_BOOST instead of explicit referencing the libs
Mar 5 2018
Needed to update the Git hash going with this release.
It is include in error reporting by ceph
Dec 31 2017
In D13699#286672, @jbeich wrote:In D13699#286484, @wjw_digiware.nl wrote:
- 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
Dec 30 2017
Move cython usage to USE_PYTHON
- 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 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.
- 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.
Aug 11 2017
@mat
I understand, and will ask on the ports-list if somebody wants to do the honnurs.
Jul 28 2017
Mar 28 2017
In D9584#210073, @feld wrote:Looks good now, builds cleanly.
Mar 25 2017
net/ceph-devel: Update the submission
Going to fix that
Mar 23 2017
@feld
Hi Mark,
Mar 20 2017
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.
Mar 13 2017
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.
Mar 9 2017
@mat
Sorry to nag, but is there a reason this does not move forward?
Feb 28 2017
@mat
Is there anything else I need to do?
Feb 24 2017
net/ceph-devel: Deleted auto file etc/rc.d/ceph
Feb 23 2017
net/ceph-devel: sorted pkg-plist