Created attachment 7343 [details] sys_statvfs() wrapper support for OpenBSD/FreeBSD/DragonFly The attached patch adds sys_statvfs() wrapper support for OpenBSD/FreeBSD/DraonFly.
Created attachment 7344 [details] sys_statvfs() wrapper support for OpenBSD/FreeBSD/DragonFly
Comment on attachment 7344 [details] sys_statvfs() wrapper support for OpenBSD/FreeBSD/DragonFly Looks good to me. Jeremy, can you ack it for 3.6.next?
Comment on attachment 7344 [details] sys_statvfs() wrapper support for OpenBSD/FreeBSD/DragonFly LGTM.
Reassigning to Karolin for inclusion in 3.6.next. Jeremy.
Pushed to v3-6-test. Will be included in the next release. Closing out bug report. Thanks!
Are waf configure checks dealt with as well ? I think that would be important not to forget.
Created attachment 7353 [details] sys_statvfs() wrapper support for OpenBSD/FreeBSD/DragonFly try #2
The initial patch although built Ok it would have also attempted to build on NetBSD which we don't want (no statfs() for recent versions and different struct members for older NetBSD). The newly attached patch reverts the changes I made to the existing autoconf statfs() check and adds another statfs() check that'll do the right thing and this ensures only building on OpenBSD/FreeBSD/DragonFly.
Karolin, would it be possible that you revert a0d51949abde68134eb35150d797387a1fb57ab7 from v3-6-test? I did test this on FreeBSD, but it makes the build fail on NetBSD. This patch needs to grow a bit in master and is not ready for 3.6. Sorry for the confusion, I should have tested on many more platforms before I give my blessing for this patch. I now ha ve installed NetBSD and can verify further patches. Volker
(In reply to comment #8) > The initial patch although built Ok it would have also attempted to build on > NetBSD which we don't want (no statfs() for recent versions and different > struct members for older NetBSD). The newly attached patch reverts the changes > I made to the existing autoconf statfs() check and adds another statfs() check > that'll do the right thing and this ensures only building on > OpenBSD/FreeBSD/DragonFly. With http://git.samba.org/?p=samba.git;a=commitdiff;h=6c1c092f079492d3 and its two parents I have pushed a patchset to master that works fine for me on OpenBSD, FreeBSD, NetBSD and Linux. I have not tried Dragonfly. Can you verify that this patchset works for you?
(In reply to comment #9) > Karolin, would it be possible that you revert > a0d51949abde68134eb35150d797387a1fb57ab7 from v3-6-test? Of course. Has been pushed a few minutes ago (14fe979a).
(In reply to comment #11) > (In reply to comment #9) > > Karolin, would it be possible that you revert > > a0d51949abde68134eb35150d797387a1fb57ab7 from v3-6-test? > > Of course. Has been pushed a few minutes ago (14fe979a). Thanks!
Created attachment 7375 [details] Improvements to statvfs() wrapper function.
Created attachment 7376 [details] Improvements to statvfs() wrapper function.
The attached patch adds support for the statvfs() wrapper to indicate read-only FS's as well as quota's support on NetBSD and HP-UX. The vfs_default code was changed to always call the statvfs wrapper function instead of doing it conditionally based on the ifdef's and only uses the FS capabilities field if the result indicates successful completion.
(In reply to comment #15) > The attached patch adds support for the statvfs() wrapper to indicate read-only > FS's as well as quota's support on NetBSD and HP-UX. The vfs_default code was > changed to always call the statvfs wrapper function instead of doing it > conditionally based on the ifdef's and only uses the FS capabilities field if > the result indicates successful completion. Thanks -- pushed to master. For the future -- could you submit your patches in "git format-patch" form? Volker
Ok. Will do. I think this stuff is ready to go back to 3.6-test. I'm not sure what the process is but here are the commits that were made to master. 71a6d334321d42fd0f02646d1649405ccf197c00 dcb1cd293364b5269aaf3b0ac0e475aeb18e9bab 8bdc2890999c850519913be0e829e9ced979ac2f f0bba969d87f0fd5c7d3f1ba001a5c9a754cd7ed I'm not sure if you want to bother with the typo fix but IMO might as well.. 341bd82fbf1f9209aae94bdbc6461805f826e39e
(In reply to comment #17) > I think this stuff is ready to go back to 3.6-test. > > I'm not sure what the process is but here are the commits > that were made to master. > > 71a6d334321d42fd0f02646d1649405ccf197c00 > dcb1cd293364b5269aaf3b0ac0e475aeb18e9bab > 8bdc2890999c850519913be0e829e9ced979ac2f > f0bba969d87f0fd5c7d3f1ba001a5c9a754cd7ed > > I'm not sure if you want to bother with the typo fix but > IMO might as well.. > > 341bd82fbf1f9209aae94bdbc6461805f826e39e Volker, as you have pushed these patches to the master branch, can I push them to v3-6-test? (Fishing for the explicit review confirmation ;-). Thanks! Karolin
This still needs to be dealt with..
ping.
As Volker wrote, this still needs to grow in master before it can maybe be backported later on to 3.6. I just saw that those patches break Tru64, which seems to have a statvfs struct like Linux does but the ifdef's currently enable to the new BSD code.
additional fixes and cleanups are now in. 7560b1cea6d2c0b2962f5802f724525fc0ec9bf9 b526a0d6730796057c5486bf07fbb6b1b79c92b4 Shall we backport the statvfs stuff to 3.6 or just close this one as fixed and let it come into the next major release?
I'd prefer to see this go into v3-6-test at this point.
given that even with small looking changes we saw regressions in the 3.6 tree that needed a number of rounds to get fixed again (see the md5 symbol bug #9037), I think we should be strict with our own policy not to get new features into stable release branches. If the BSD maintainers want to backport the fixes to their ports collections they can do that of course. Upstream we should not. As this is fixed in master I'll close this as fixed now.