home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.next.misc:19573 comp.sys.next.advocacy:2225
- Path: sparky!uunet!overload!dillon
- From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
- Newsgroups: comp.sys.next.misc,comp.sys.next.advocacy
- Subject: Re: New release of SLIP software
- Distribution: world
- Message-ID: <dillon.0noh@overload.Berkeley.CA.US>
- References: <1992Sep13.021511.22878@ni.umd.edu>
- Date: 13 Sep 92 09:08:00 PST
- Organization: Not an Organization
- Lines: 28
-
- >In article <1992Sep13.021511.22878@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
- >
- >I've left a new version of my SLIP software on SONATA.CC.PURDUE.EDU and
- >CS.ORST.EDU. Look for the files:
- >
- >-rw-r--r-- 1 louie 4462 Sep 4 22:27 SLIP_920904.README
- >-rw-r--r-- 1 louie 291 Sep 4 22:27 SLIP_920904.md5
- >-rw-r--r-- 1 louie 532480 Sep 4 22:27 SLIP_920904.tar
-
- Cool stuff. One question -- when you patch the kernel do you clear the
- 68040's code cache? I'm not sure exactly what that entails from user
- mode, but it's probably necessary. Since the mods are being written as
- data, they are going into the data cache and not the code cache so if
- entries corresponding to those code locations exist in the code cache
- strange things will happen. Since the 68040 uses a physical memory
- cache it is unlikely that the kernel is clearing it every context
- switch (which is good... you have to clear the cache every switch on an
- 030 because the 030 has a VM cache).
-
- -Matt
-
- --
-
- Matthew Dillon dillon@Overload.Berkeley.CA.US
- 1005 Apollo Way uunet.uu.net!overload!dillon
- Incline Village, NV. 89451 ham: KC6LVW (no mail drop)
- USA Sandel-Avery Engineering (702)831-8000
-
-