public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ronald Wahl <Ronald.Wahl@informatik.tu-chemnitz.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Q] Looking for an emulation for CMOV* instructions.
Date: 11 Jan 2002 19:24:42 +0100	[thread overview]
Message-ID: <m2g05cn3th.fsf@goliath.csn.tu-chemnitz.de> (raw)
In-Reply-To: <E16Opxl-00066O-00@the-village.bc.nu>

On Fri, 11 Jan 2002 00:54:29 +0000 (GMT), Alan Cox wrote:

>> The compiler doesn't know, where the binary runs later. Or do you mean,
>> that it has to insert some code that checks for the existance of these
>> instructions during program start? Ok that would be a solution, but how
>> do you do this for libraries that are not run in itself?

> It means the compiler for -m686 shouldn't have assumed cmov was
> available

It's not the compiler that is responsible for it. At least in my case.
The problem is that if you compile the glibc than some assembler code
gets included into glibc.  So the problem here is glibc and not gcc.
Ok, the way to go for me now will be to make a new glibc without this
instructions. But I still think it would be a step to more fault
tolerance (or tolerance to goofy admins ;-) if we could have an
emulation of this. If I find some time I will do this...

>> but the costs of automatically catching such errors are little in
>> respect of the benefit you get. A running system is always better than
>> a unusable one even if it was the admins fault.

> Then while you are it you can make the kernel magically recover from rm -rf /
> or rm * in /lib...

Let the FS driver copy all modified sectors into a hidden log on the
disk (fixed or dynamic in size or as a ringbuffer). Then e.g during
kernel startup in case you removed most of the system you might be asked
to recover from some point. Such concepts are used by software like
HDD-Sheriff but one level below (disc sector level). On filesystem level
it makes more sense since you may recover partially. All that will bloat
the kernel but it would be possible. This case is one that has (very)
high costs. Not that I want this but I want to show that there _are_
ways to do it.

ron

-- 
/\/\  Dipl.-Inf. Ronald Wahl                /\/\        C S N         /\/\
\/\/  ronald.wahl@informatik.tu-chemnitz.de \/\/  ------------------  \/\/
/\/\  http://www.tu-chemnitz.de/~row/       /\/\  network and system  /\/\
\/\/  GnuPG/PGP key available               \/\/    administration    \/\/

  parent reply	other threads:[~2002-01-11 18:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-10 23:08 [Q] Looking for an emulation for CMOV* instructions Ronald Wahl
2002-01-10 23:28 ` Alan Cox
2002-01-11  0:08   ` Ronald Wahl
2002-01-11  0:26     ` Alan Cox
2002-01-11  0:39       ` Ronald Wahl
2002-01-11  0:54         ` Alan Cox
2002-01-11  1:09           ` Martin Eriksson
2002-01-11  1:42             ` Timothy Covell
2002-01-11  2:16             ` Alan Cox
2002-01-11 18:24           ` Ronald Wahl [this message]
2002-01-11 22:18           ` Richard Henderson
2002-01-11 23:07             ` Alan Cox
2002-01-11 23:26               ` Albert D. Cahalan
2002-01-11 23:40                 ` Alan Cox
2002-01-16 15:18               ` Jamie Lokier
2002-01-16 16:16                 ` Richard B. Johnson
2002-01-16 17:48                   ` Ronald Wahl
2002-01-16 17:30                 ` Dave Jones
2002-01-17 11:54                 ` Maciej W. Rozycki
2002-01-11 19:59   ` Hans-Peter Jansen
2002-01-11 20:05     ` Ronald Wahl
2002-01-11 23:19       ` Alan Cox
2002-01-12  6:27   ` Pavel Machek
2002-04-12 20:48     ` H. Peter Anvin
2002-01-12  6:34   ` Pavel Machek
2002-01-18 17:38   ` David Woodhouse
2002-01-18 22:01     ` Pavel Machek
2002-01-11 23:25 ` Alistair Riddell
     [not found] <fa.eln67tv.a4io16@ifi.uio.no>
     [not found] ` <fa.gp0gofv.1p4se16@ifi.uio.no>
2002-01-11  8:12   ` Giacomo Catenazzi
  -- strict thread matches above, loose matches on Subject: below --
2002-01-11  9:25 willy tarreau
2002-01-11 17:55 ` Ronald Wahl
     [not found] <m26669olcu.fsf@goliath.csn.tu-chemnitz.de.suse.lists.linux.kernel>
     [not found] ` <E16Oocq-0005tX-00@the-village.bc.nu.suse.lists.linux.kernel>
2002-01-11  9:54   ` Andi Kleen
2002-01-12  6:31     ` Pavel Machek
2002-01-12  7:52     ` H. Peter Anvin
     [not found] <200201111845.g0BIjS2318104@saturn.cs.uml.edu>
2002-01-12  9:00 ` willy tarreau
2002-01-12 18:57   ` Alan Cox
2002-01-12 10:48 Adam J. Richter
2002-01-12 11:25 ` David Weinehall
2002-01-12 13:18 ` Brian Gerst
2002-01-12 20:43 ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2g05cn3th.fsf@goliath.csn.tu-chemnitz.de \
    --to=ronald.wahl@informatik.tu-chemnitz.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox