Oh believe ,e I agree. But here we run into the dilbert principal and we
really should be sarter than the IT Diredtor that makes stupid decisions and overrides
thier admins with insane schedules that prevent a full reading of the docs. 8-(
Believe me, it's far more common a situation
On Mon, 5 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > In an __init function, have some code that will trigger the bug.
> > > This can be used to disable Reiserfs if the compiler was bad.
> > > Then the admin gets a printk() and the Reiserfs mount fails.
> >
> > Thats actually
Alan Cox wrote:
>
> > No. There are *many* other compilers out there which are much *more* broken
> > then anything RedHat has recently shipped. Unfortunatly, there is no easy
> > way to accuratly test for such bugs (because once they can be boiled down to
> > a simple test they are very rapidly
Alan Cox wrote:
>
> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
>
> Thats actually quite doable. I'll see about dropping the test into -ac
Alan Cox wrote:
>
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a
> No. There are *many* other compilers out there which are much *more* broken
> then anything RedHat has recently shipped. Unfortunatly, there is no easy
> way to accuratly test for such bugs (because once they can be boiled down to
> a simple test they are very rapidly fixed, what's left is
> In an __init function, have some code that will trigger the bug.
> This can be used to disable Reiserfs if the compiler was bad.
> Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll see about dropping the test into -ac that
way.
-
To unsubscribe from
> administrator that has worked in large multi hundred million dollar compani=
> es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> ion IS the right answer. If the gcc people need to compile with the .96 rh =
> version then they can apply a removal patch hans provides
administrator that has worked in large multi hundred million dollar compani=
es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
ion IS the right answer. If the gcc people need to compile with the .96 rh =
version then they can apply a removal patch hans provides in
In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll see about dropping the test into -ac that
way.
-
To unsubscribe from
No. There are *many* other compilers out there which are much *more* broken
then anything RedHat has recently shipped. Unfortunatly, there is no easy
way to accuratly test for such bugs (because once they can be boiled down to
a simple test they are very rapidly fixed, what's left is voodoo).
Alan Cox wrote:
administrator that has worked in large multi hundred million dollar compani=
es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
ion IS the right answer. If the gcc people need to compile with the .96 rh =
version then they can apply a removal
Alan Cox wrote:
In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll see about dropping the test into -ac that
way.
Alan Cox wrote:
No. There are *many* other compilers out there which are much *more* broken
then anything RedHat has recently shipped. Unfortunatly, there is no easy
way to accuratly test for such bugs (because once they can be boiled down to
a simple test they are very rapidly fixed,
On Mon, 5 Feb 2001, Hans Reiser wrote:
Alan Cox wrote:
In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
Thats actually quite doable. I'll
Oh believe ,e I agree. But here we run into the dilbert principal and we
really should be sarter than the IT Diredtor that makes stupid decisions and overrides
thier admins with insane schedules that prevent a full reading of the docs. 8-(
Believe me, it's far more common a situation
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
> From the debate raging here is what I gathered is acceptable
>
> make it blow up fataly and immediatly if it detects Red Hat + gcc
>2.96-red_hat_broken(forgot version num)
> make it provide a URL to get the patch to
Brian Wolfe writes:
> I hate to say it but I think Hans might have the right answer here.
> As an administrator that has worked in large multi hundred million
> dollar companies where 1 hour of downtime == $75,000 in lost income
...
> From the debate raging here is what I gathered is
> > can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> > fails with untrusted compilers it is just not selectable.
>
> What kind of crap is this?
> It is not the kernel's job to work around RedHat bugs.
The kernel actually works round gcc 2.7.2, egcs-1.1.2 and
can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
fails with untrusted compilers it is just not selectable.
What kind of crap is this?
It is not the kernel's job to work around RedHat bugs.
The kernel actually works round gcc 2.7.2, egcs-1.1.2 and gcc-2.95
Brian Wolfe writes:
I hate to say it but I think Hans might have the right answer here.
As an administrator that has worked in large multi hundred million
dollar companies where 1 hour of downtime == $75,000 in lost income
...
From the debate raging here is what I gathered is acceptable
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
From the debate raging here is what I gathered is acceptable
make it blow up fataly and immediatly if it detects Red Hat + gcc
2.96-red_hat_broken(forgot version num)
make it provide a URL to get the patch to
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <[EMAIL PROTECTED]>
wrote:
>How about a simple patch to the top level makefile that checks the gcc
>version then prints a distinct message ..'this compiler hasn't been approved
>for compiling the kernel', sleeping for one second, then continuing on.
Thus spake J . A . Magallon ([EMAIL PROTECTED]):
> > How about a simple patch to the top level makefile that checks the gcc
> > version then prints a distinct message ..'this compiler hasn't been approved
> > for compiling the kernel', sleeping for one second, then continuing on. This
> >
On 02.03 David Ford wrote:
> How about a simple patch to the top level makefile that checks the gcc
> version then prints a distinct message ..'this compiler hasn't been approved
> for compiling the kernel', sleeping for one second, then continuing on. This
> solution doesn't stop compiling and
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and makes a visible indicator without
On 02.03 David Ford wrote:
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution doesn't stop compiling and
Thus spake J . A . Magallon ([EMAIL PROTECTED]):
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on. This
solution
On Sat, 03 Feb 2001 00:57:45 -0800, David Ford [EMAIL PROTECTED]
wrote:
How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on.
Ion Badulescu <[EMAIL PROTECTED]> writes:
> On Fri, 2 Feb 2001, Alan Cox wrote:
>
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put
On Sat, 3 Feb 2001, Hans Reiser wrote:
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
Alan Cox wrote:
>
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans
On Fri, Feb 02, 2001 at 09:57:39PM +, Alan Cox wrote:
: > As it stands, there is no way to determine programatically whether
: > gcc-2.96 is broken or now. The only way to do it is to check the RPM
: > version -- which, needless to say, is a bit difficult to do from the
: > C code about to be
> As it stands, there is no way to determine programatically whether
> gcc-2.96 is broken or now. The only way to do it is to check the RPM
> version -- which, needless to say, is a bit difficult to do from the
> C code about to be compiled. So I can't really blame Hans if he decides
> to outlaw
On Fri, 2 Feb 2001 16:46:45 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote:
>> :It is the original one. I'll try with the -69:
>> :
>> With 2.96-69 the reiserfs seems to work well.
>> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
>
> Excellent. Im just glad to
> : It is the original one. I'll try with the -69:
> :
> With 2.96-69 the reiserfs seems to work well.
> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
Excellent. Im just glad to know its a fixed bug.
-
To unsubscribe from this list: send the line "unsubscribe
Jan Kasprzak wrote:
: :
: : 2.96-69 should be ok (thats the one I've been using without trouble). The
: : original one with RH 7.0 off the CD does miscompile a few kernel things.
:
: It is the original one. I'll try with the -69:
:
With 2.96-69 the reiserfs seems to work well.
Alan Cox wrote:
: > Hans Reiser wrote:
: >: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: >: reiserfs Makefile.
: >:
: > OK, thanks. It works with older compiler (altough I use gcc 2.96
: > for a long time for compiling various 2.[34] kernels without
> Hans Reiser wrote:
> : This is why our next patch will detect the use of gcc 2.96, and complain, in the
> : reiserfs Makefile.
> :
> OK, thanks. It works with older compiler (altough I use gcc 2.96
> for a long time for compiling various 2.[34] kernels without problem).
Ok which 2.96
Hans Reiser wrote:
: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: reiserfs Makefile.
:
OK, thanks. It works with older compiler (altough I use gcc 2.96
for a long time for compiling various 2.[34] kernels without problem).
-Yenya
--
\ Jan "Yenya"
This is why our next patch will detect the use of gcc 2.96, and complain, in the
reiserfs Makefile.
Hans
Jan Kasprzak wrote:
>
> Hello,
>
> with ReiserFS support in 2.4.1 I have decided to give it a try.
> I created a filesystem on a spare partition, mounted it as /mnt,
> and
Hello,
with ReiserFS support in 2.4.1 I have decided to give it a try.
I created a filesystem on a spare partition, mounted it as /mnt,
and tried to use it. The kernel crashed - I am able to reproduce it
with the following steps:
- boot linux with init=/bin/bash
- [optional]
Hello,
with ReiserFS support in 2.4.1 I have decided to give it a try.
I created a filesystem on a spare partition, mounted it as /mnt,
and tried to use it. The kernel crashed - I am able to reproduce it
with the following steps:
- boot linux with init=/bin/bash
- [optional]
This is why our next patch will detect the use of gcc 2.96, and complain, in the
reiserfs Makefile.
Hans
Jan Kasprzak wrote:
Hello,
with ReiserFS support in 2.4.1 I have decided to give it a try.
I created a filesystem on a spare partition, mounted it as /mnt,
and tried
Hans Reiser wrote:
: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: reiserfs Makefile.
:
OK, thanks. It works with older compiler (altough I use gcc 2.96
for a long time for compiling various 2.[34] kernels without problem).
-Yenya
--
\ Jan "Yenya"
Hans Reiser wrote:
: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: reiserfs Makefile.
:
OK, thanks. It works with older compiler (altough I use gcc 2.96
for a long time for compiling various 2.[34] kernels without problem).
Ok which 2.96 compiler
Alan Cox wrote:
: Hans Reiser wrote:
: : This is why our next patch will detect the use of gcc 2.96, and complain, in the
: : reiserfs Makefile.
: :
: OK, thanks. It works with older compiler (altough I use gcc 2.96
: for a long time for compiling various 2.[34] kernels without problem).
: It is the original one. I'll try with the -69:
:
With 2.96-69 the reiserfs seems to work well.
Sorry for the confusion, I forgot to upgrade the gcc on my machine.
Excellent. Im just glad to know its a fixed bug.
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, 2 Feb 2001 16:46:45 + (GMT), Alan Cox [EMAIL PROTECTED] wrote:
:It is the original one. I'll try with the -69:
:
With 2.96-69 the reiserfs seems to work well.
Sorry for the confusion, I forgot to upgrade the gcc on my machine.
Excellent. Im just glad to know its a
As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he decides
to outlaw
On Fri, Feb 02, 2001 at 09:57:39PM +, Alan Cox wrote:
: As it stands, there is no way to determine programatically whether
: gcc-2.96 is broken or now. The only way to do it is to check the RPM
: version -- which, needless to say, is a bit difficult to do from the
: C code about to be
Alan Cox wrote:
As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he
On Sat, 3 Feb 2001, Hans Reiser wrote:
That said, my opinion is that bug reporting load is not as important as bug
avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
Ion
Ion Badulescu [EMAIL PROTECTED] writes:
On Fri, 2 Feb 2001, Alan Cox wrote:
Oh I can see why Hans wants to cut down his bug reporting load. I can also
say from experience it wont work. If you put #error in then everyone will
mail him and complain it doesnt build, if you put #warning in
55 matches
Mail list logo
