[haiku-commits] Re: haiku: hrev49315 - in src: tests/add-ons/kernel/file_systems/udf/r5 tests/add-ons/kernel/file_systems/bfs/r5 tests/add-ons/kernel/file_systems/udf/r5/drive_setup_addon add-ons/kernel/file_systems/udf/drive_setup_addon tools/bfs_shell

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 22 Jun 2015 19:25:22 +0200

On Mon, Jun 22, 2015 at 01:17:14PM -0400, gus knight wrote:

On Mon, Jun 22, 2015 at 12:59 PM, <pulkomandy@xxxxxxxxxxxxx> wrote:
Axel comented on the commit saying it probably was not a good idea, but
no action was
taken. Should we setup a better commit review system?

[ Adrien Destugues <pulkomandy@xxxxxxxxxxxxx> ]

Axel's comment on the commit was that it was "possibly unsafe", and he
didn't know if the GCC maintainers had fixed the bug (our version of
GCC2 is newer than the one that shipped with BeOS's). I hadn't noticed
any problems in testing it, and I still haven't run into any problems
after daily use of Haiku on a GCC2Hybrid. So no, I'm not convinced
this is the problem.

We have been using gcc 2.95.3 for a very long time, including on BeOS,
and I think that is the version this message is referring to.

Anyway, as I said in the commit message, it is not ok to change this
because it "looks ok". Either we track back what was wrong and test if
the problem is still there, or, we at least run our test suites and FS
stree tests (bonnie++ or similar) to make sure everything is ok.

I never had such major disk corruption since I started using BeOS (it's
been more than 10 years), and I didn't do anything special when it
happened this time (as I said, it did this while shutting down or while
booting). So, something is very wrong. Since there was no other recent
change, I'm assuming this is the problem.


However, if you are convinced this is the problem, we should seriously
consider compiling the kernel with GCC4, even on GCC2hybrids. Is there
any technical reason *not* to do this? Can we make it impossible to
compile the kernel with GCC2 altogether?

We are binary compatible with BeOS, also at the driver level. This
requires a gcc2 kernel. If you are not happy with that, you can switch
to the x86_64 version, which is the right one to run if you don't care
about binary compatibility. If not already done, we can change the
Jamfiles to lower optimizations only on gcc2.

--
Adrien.

Other related posts: