Re: silly [< >] and other excess

[Russell King <rmk@arm.linux.org.uk>]

Andries.Brouwer@cwi.nl writes:
>     From rmk@flint.arm.linux.org.uk Wed Nov 22 19:20:52 2000
>     They provide no information to the human reader, but they tell klogd
>     (and other tools) that the enclosed value is a kernel address that
>     should be looked up in the System.map file and decoded into name +
>     offset.
> 
> Of course. But since there is no information in [< >]
> (their presence is syntactically determined, not semantically)
> the tools you mention can be trivially patched to work without
> this [< >] kludge. On the other hand, when the system panics
> often klogd and similar nice programs do not run at all, and
> hence are unable to do any good. All information available
> is the information on the screen, and it is really a pity
> to lose EIP and get a few parentheses instead.

Well, in my experience, values of PC (or EIP is x86 speak) rarely
appear over column 50 on the screen.  Therefore, removing them is
only going to save width, not height.

Also, have you considered that not every oops is formatted exactly
the same way on every architecture?  In fact, an oops on ARM looks
like:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1e90000
*pgd = 01e94001, *pmd = 01e94001, *pte = 0000308b, *ppte = 0000300a
Internal error: Oops: 0
CPU: 0
pc : [<c280007c>]    lr : [<c00251f8>]
sp : c1e97f08  ip : c1e97ec0  fp : c1e97f14
r10: c1e96000  r9 : 00000004  r8 : ffffffea
r7 : 02029220  r6 : c1e37000  r5 : c2800000  r4 : 00000000
r3 : ef9f0000  r2 : 00000000  r1 : 00000000  r0 : 000001db
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 1E9117D  Table: 01E9117D  DAC: 00000015
Process insmod (pid: 9, stackpage=c1e97000)
Stack:
c1e97ee0:                                                        c00251f8 c280007c
c1e97f00: 60000013 ffffffff c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000
c1e97f20: c01f3680 00000060 c011d48c c2800060  00005e00 00000000 00000000 00000000
c1e97f40: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
c1e97f60: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
c1e97f80: 00000000 bfffec64 02021928 60000010  c2800000 c00169e4 00000080 0201bbe8
c1e97fa0: 00000000 c1e97fb0 c0016860 c0025acc  bfffec64 c001bb54 0201bbe8 02029220
c1e97fc0: 00000000 00000038 bfffec64 02021928  02019f10 c2800000 00005e00 0201bbe8
c1e97fe0: 0201bbe8 bffffe60 400e4c90 bfffec28  020031e8 400e4c9c 60000010 0201bbe8
Backtrace:
Function entered at [<c2800060>] from [<c0026194>]
Function entered at [<c0025ac0>] from [<c0016860>]
Code: e51f2024 e5923000 (e5813000) e3a00000 e51f3030

where each number in [< >] should be looked up in System.map.  Do you
propose to teach klogd and ksymoops every single oops format style?

If no, then don't make this change to the kernel.  If yes, then you've
got a big job on your hands.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/