Daily blurbs Jan. 2006

Plans

daily blurbs


15 Jan 2006 (Sun)

10:21:02 # Life How to get a X session out of pbuilder. To get an X display, I have done the following: start Xnest :10. outside, I have done xauth list to show my key for :10 (which I have prepared earlier with xauth add). Then, I just need to install xbase-clients inside pbuilder session, and do xauth add inside chroot. Applications inside chroot can now connect to Xnext server outside of chroot.

outside of chroot
$ xauth list
$ Xnest :10

inside of chroot
# export XAUTHORITY=/root/.Xauthority
# xauth add dancer64/unix:10  MIT-MAGIC-COOKIE-1   XXXX
# DISPLAY=localhost:10 xterm
	

17:34:31 # Life I've noticed that I assembled a list of a few things I'd like to see in Debian on January 2005. I'd like to review them.

14 Jan 2006 (Sat)

16:51:47 # Life shell scripting trickery that I was trapped in today. I noticed that when I'm using an expression like (exit 1) to exit 1 from inside subshell, shell wouldn't exit even when set -ex is specified. Is this a bug?

#!/bin/bash
set -ex

(
    set -ex
    exit 1
)

echo $?

echo hello
	

21:49:43 # Life What's your kernel memory address like? I had an urge to know what kind of memory mapping a powerpc machine had. I couldn't really figure out how to find out which memory address the kernel resided, or how to find out the physical memory address from a virtual memory address. Apparently, there is a virt_to_phys function in the kernel which does exactly this. I was surprised to discover that virt_to_phys gives me physical address 0 for virtual address 0xc0000000 (PAGE_OFFSET). If I was running on x86, I would be worried about real-mode code running around with a NULL-pointer. Is powerpc any different?

REAL ksh: #include <asm/io.h>
REAL ksh: printk("%x\n", PAGE_OFFSET);
  Building modules, stage 2.
KMSG: <4>c0000000

REAL ksh: printk("%lx\n", virt_to_phys((void*)PAGE_OFFSET));
  Building modules, stage 2.
KMSG: <4>0
	

I was a bit surprised with the following result from x86_64, am I missing something?

REAL ksh: printk("%lx\n", PAGE_OFFSET);
  Building modules, stage 2.
KMSG: <4>ffff810000000000

REAL ksh: printk("%lx\n", virt_to_phys((void*)PAGE_OFFSET));
  Building modules, stage 2.
KMSG: <4>0
REAL ksh:   
	

12 Jan 2006 (Thu)

09:31:05 # Life experimental moved. I see a experimental-is-in-dists-now file on the ftp server. I didn't really know until a bug was filed against pbuilder. Was there an announcement? This requires change on end-user systems. There was an answer to a question, which I didn't notice.

8 Jan 2006 (Sun)

23:07:00 # Life Wondered if you can delete[] something you have malloc'd? I received a bugreport 342156, and I went for a search on why this program seems to be working without a problem. For the case of delete[] of void*, void* actually has a destructor defined, _ZdlPv in libstdc++. A desctructor of a void* will call free, after checking if the pointer is non-NULL, as in plain C: if(a) { free(a);}. g++ will warn you if you use this construct, but it will function, in practice. However, this topic apparently is a popular one covered in a few articles, such as this one which tells you it's a sin to mix malloc/free new/delete. Unless you are bored enough to be able to follow compiler intrinsics to the minor details, it's better to keep away from such practice.

(gdb) disassemble _ZdlPv
Dump of assembler code for function _ZdlPv:
0x00002aaaaac7bbc0 <_ZdlPv+0>:  test   %rdi,%rdi
0x00002aaaaac7bbc3 <_ZdlPv+3>:  je     0x2aaaaac7bbd0 <_ZdlPv+16>
0x00002aaaaac7bbc5 <_ZdlPv+5>:  jmpq   0x2aaaaac11138 <free@plt>
0x00002aaaaac7bbca <_ZdlPv+10>: data16
0x00002aaaaac7bbcb <_ZdlPv+11>: data16
0x00002aaaaac7bbcc <_ZdlPv+12>: nop
	

Of course, you could have actually seen the source, gcc-4.0/libstdc++-v3/libsupc++/del_op.cc. But hey..

7 Jan 2006 (Sat)

14:14:06 # Life First upload for this new year. I've uploaded new versions of whizzytex, binfmtc, cowdancer, pbuilder. I started using pbuilder-testsuite for my own packages. My scripts are set up such that unless testsuites pass, they won't be queued for upload. It took a bit of time until all those testsuites passed, but has a fuzzy warm feeling that I've tested those packages. Nice.

18:28:34 # Life Using docdiff/emacs/svn more effectively. I have a local hack that makes docdiff a bit more whizzy than it is. I embed ctrl-A to the current location in emacs buffer, hand it over to docdiff, and docdiff will change that to an HTML anchor. That way, I can jump to the current editing location when the target docdiff is quite large. Here is the patch with an accompanying elisp.

2 Jan 2006 (Mon)

23:30:15 # Life oprofile patch for MPC7447A. I'll just drop here what I've done so far; it's probably already obsolete since 2.6.15 is going to be released, and somebody else is already working on an implementation. This was a quick hack to make it work enough on my system. patch against kernel 2.6.14 patch against oprofile 0.9.1

1 Jan 2006 (Sun)

00:08:54 # Life The real ksh. I've implemented the real ksh for hackers. It's a shell that interprets C code line-by-line, and runs each line of code in kernel mode (by building modules with that line on the fly and doing an insmod/rmmod). It's pretty slow, and doesn't feel too interactive, but here it goes. I'm sure most people hacking on the kernel have this kind of setup already. Here is the full text (binfmtc-style). An example transcript follows:

$ sudo ./realksh.c
REAL ksh: printk ("hello\n");
  Building modules, stage 2.
KMSG: <4>hello

REAL ksh: printk ("%x\n", mfmsr());
  Building modules, stage 2.
KMSG: <4>9032

REAL ksh: printk ("%x\n", mfspr(SPRN_MMCR0));
  Building modules, stage 2.
KMSG: <4>0

REAL ksh:
	

15:43:17 # Life alioth disk full. I'll note it down here also, since IRC isn't very active at the moment. alioth server (cvs.alioth.debian.org, haydn) is disk full. My assertion is that org/ldap/log.* files are accumulating too fast. It's consisting 20GB, and it has accumulated 20GB of such files apparently in the past two weeks.


Junichi Uekawa

$Id: 200601.html.en,v 1.17 2006/01/15 13:31:05 dancer Exp $