home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: alt.hackers
- Path: sparky!uunet!usc!rpi!batcomputer!bouncer
- From: eirik@elf.TN.Cornell.EDU (Eirik Fuller)
- Subject: stripslash
- Message-ID: <1992Dec28.012047.29726@tc.cornell.edu>
- Sender: news@tc.cornell.edu
- Nntp-Posting-Host: earache.tc.cornell.edu
- Organization: Cornell Theory Center
- Date: Mon, 28 Dec 1992 01:20:47 GMT
- Approved: The Slash Stripper
- Lines: 51
-
- I first installed SunOS 4.1.3 during a CPU upgrade; the newer CPU,
- unlike the older one, is not constrained, by obsolescence, to SunOS
- 4.1.1, though I think it is constrained by a slightly different sort
- of obsolescence to 4.1.3, or at best any subsequent 4.1.? releases.
- Not that I'd ever want to run Solaris 2 ...
-
- One goal in installing 4.1.3 was to shrink the number of applicable
- patches. Perhaps this goal is misguided; after all, a smaller number
- of patches for an equal number of bugs might not be the best thing to
- have. However, I was driven in part by a naive hope that the number
- of stale old bugs which had been fixed was larger than the number of
- new bugs.
-
- As it happens, I did find one especially annoying new "feature" of
- SunOS 4.1.3, one which, among other things, invalidated a GNU emacs
- primitive (file-name-as-directory). I was on the verge of deciding to
- retrograde to 4.1.2 (and upgrade our 4.1.1 machines only to 4.1.2),
- when a stubborn streak set in. After some poking around, I came up
- with this:
-
-
- 19:34:53 $ adb -w vfs_lookup.o
- stripslash?3i
- _stripslash:
- _stripslash: ld [%o0 + 0x8], %o2
- cmp %o2, 0x1
- blu _stripslash + 0x64
- stripslash+0x64?i
- _stripslash+0x64: jmp %o7 + 0x8
- stripslash+0x64?X
- _stripslash+0x64: 81c3e008
- stripslash?W 0x81c3e008
- _stripslash: 0xd4022008 = 0x81c3e008
- ?i
- _stripslash:
- _stripslash: jmp %o7 + 0x8
- 19:36:13 $
-
-
- Note that the symbol stripslash does not exist in 4.1.1 or 4.1.2
- kernels, only (from what I've seen) in 4.1.3 kernels. What this
- means, I think, is that any kernel code that calls it should now work
- the same way as the earlier kernel code that didn't call it, except
- for the small overhead of calling the newly defined noop.
-
- I can't for the life of me imagine what "problem" this stripslash
- function is supposed to "fix" ... it seems more likely that a Sun
- employee by the name of Murphy knew it would annoy me. :-)
-
- Left as an exercise: chase down the callers of this function and patch
- them not to call it. :-)
-