home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!fl0p+
- From: fl0p+@andrew.cmu.edu (Frank T Lofaro)
- Newsgroups: comp.os.linux
- Subject: Re: Some considerations when making a new Linux kernel
- Message-ID: <YfN2DrC00VpZE_2kl5@andrew.cmu.edu>
- Date: 25 Jan 93 07:31:35 GMT
- Article-I.D.: andrew.YfN2DrC00VpZE_2kl5
- References: <1993Jan23.111158.26550@athena.mit.edu>
- <1993Jan24.005436.578@unislc.uucp>
- Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
- Lines: 14
- In-Reply-To: <1993Jan24.005436.578@unislc.uucp>
-
- Excerpts from netnews.comp.os.linux: 24-Jan-93 Re: Some considerations
- whe.. Ed Carp@unislc.uucp (972)
-
- >Also, make sure that the lines in mm/memory.c that bomb processes that write
- >to code space are commented out (look for SEGV) if you are running uucp or
- >certain releases of getty_ps. I have to do that, because the latest
- version of
- >getty_ps I can find will thrash if I don't.
-
- NO! Don't break the kernel because you have broken software, fix the
- software. Personally, I might want to even change the kernel so that it
- not only does a SEGV, but instead does a SIGKILL and an unlink() of the
- offending program. :) But seriously, backwards compatibility is a very
- backwards way to go.
-