NetBSD/amd64 current on Toshiba dynabook R63/PS

はじめに

Vaio Pro 11を使っていましたが、早々にキートップが外れる、SSDが外れる、SSDが遅いと言う問題に当たってしまいました。確かにDRMKMSにもちゃんと対応していて、良いマシンですが、結局東芝の直販サイトで安売りしているdynabook R63/PSに乗り換えることになってしまいました。 ここでは、dynabook R63/PSで、NetBSD/amd64 current (6.99.24)を使う方法について、書きたいと思います。

サポート状況

最初にdmesgを示します。これは、GENERICカーネルでdtraceサポートを有効化しただけのカーネルです。

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 7.99.24 (DTRACE7) #271: Mon Dec 14 23:27:23 JST 2015
 ryo_on@brownie:/usr/world/7.99/amd64/obj/sys/arch/amd64/compile/DTRACE7
total memory = 8103 MB
avail memory = 7849 MB
rnd: seeded with 128 bits
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
TOSHIBA dynabook R63/PS (PRB63PS-NDC)
mainbus0 (root)
ACPI: RSDP 0x00000000000F0030 000014 (v00 TOSHIB)
ACPI: RSDT 0x00000000D90ED000 000068 (v01 TOSHIB A0096    00000003      01000013)
ACPI: FACP 0x00000000D90EC000 00010C (v05 TOSHIB A0096    00000003 LOHR 0000005F)
ACPI: DSDT 0x00000000D90CF000 01264F (v02 TOSHIB A0096    20150216 INTL 20130927)
ACPI: FACS 0x00000000D9099000 000040
ACPI: HPET 0x00000000D90EB000 000038 (v01 TOSHIB A0096    00000001 LOHR 0000005F)
ACPI: APIC 0x00000000D90EA000 0000BC (v01 TOSHIB A0096    00000001 LOHR 0000005F)
ACPI: MCFG 0x00000000D90E9000 00003C (v01 TOSHIB A0096    00000001 LOHR 0000005F)
ACPI: ASF! 0x00000000D90E8000 0000A0 (v32 TOSHIB A0096    00000001 LOHR 0000005F)
ACPI: TCPA 0x00000000D90E7000 000032 (v02 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: BOOT 0x00000000D90E6000 000028 (v01 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: MSDM 0x00000000D90E5000 000055 (v03 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: SLIC 0x00000000D90E4000 000176 (v01 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: DBGP 0x00000000D90E3000 000034 (v01 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: SSDT 0x00000000D90CE000 0003F9 (v02 TOSHIB SataAhci 00001000 INTL 20130927)
ACPI: SSDT 0x00000000D90C8000 00060D (v02 TOSHIB MacUniq2 00001000 INTL 20130927)
ACPI: SSDT 0x00000000D90C7000 0005E6 (v02 PmRef  Cpu0Ist  00003000 INTL 20130927)
ACPI: SSDT 0x00000000D90C6000 000B60 (v02 CpuRef CpuSsdt  00003000 INTL 20130927)
ACPI: SSDT 0x00000000D90C4000 0012DF (v02 SaSsdt SaSsdt   00003000 INTL 20130927)
ACPI: DMAR 0x00000000D90C3000 0000D8 (v01 INTEL  BDW      00000001 INTL 00000001)
ACPI: FPDT 0x00000000D90E2000 000044 (v01 TOSHIB A0096    00000000 LOHR 0000005F)
ACPI: All ACPI Tables successfully acquired
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 0x20, 40 pins
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, id 0x306d4
cpu1 at mainbus0 apid 1
cpu1: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, id 0x306d4
cpu2 at mainbus0 apid 2
cpu2: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, id 0x306d4
cpu3 at mainbus0 apid 3
cpu3: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, id 0x306d4
acpi0 at mainbus0: Intel ACPICA 20150717
acpi0: X/RSDT: OemId , AslId <    ,01000013>
acpi0: MCFG: segment 0, bus 0-63, address 0x00000000f8000000
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFFE821F6F8410 0003D3 (v02 PmRef  Cpu0Cst  00003001 INTL 20130927)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFFE810E845010 0005AA (v02 PmRef  ApIst    00003000 INTL 20130927)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFFE810E7283D0 000119 (v02 PmRef  ApCst    00003000 INTL 20130927)
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000
acpivga0 at acpi0 (GFX0): ACPI Display Adapter
acpiout0 at acpivga0 (DDC1, 0x0400): ACPI Display Output Device
acpiout0: brightness levels: [0-100]
acpiout1 at acpivga0 (DDC2, 0x0300): ACPI Display Output Device
acpiout2 at acpivga0 (DDC3, 0x0301): ACPI Display Output Device
acpiout3 at acpivga0 (DDC4, 0x0302): ACPI Display Output Device
acpiout4 at acpivga0 (DDC5, 0x0303): ACPI Display Output Device
acpiout5 at acpivga0 (DDC6, 0x0006): ACPI Display Output Device
acpiout6 at acpivga0 (DDC7, 0x0007): ACPI Display Output Device
acpiout7 at acpivga0 (DDC8, 0x0008): ACPI Display Output Device
acpiout8 at acpivga0 (DDC9, 0x0009): ACPI Display Output Device
acpiout9 at acpivga0 (DDCA, 0x000a): ACPI Display Output Device
acpiout10 at acpivga0 (DDCB, 0x000b): ACPI Display Output Device
acpiout11 at acpivga0 (DDCC, 0x000c): ACPI Display Output Device
acpiout12 at acpivga0 (DDCD, 0x000d): ACPI Display Output Device
acpiout13 at acpivga0 (DDCE, 0x000e): ACPI Display Output Device
acpiout14 at acpivga0 (DDCF, 0x000f): ACPI Display Output Device
acpivga0: unknown output device acpiout5
acpivga0: unknown output device acpiout6
acpivga0: unknown output device acpiout7
acpivga0: unknown output device acpiout8
acpivga0: unknown output device acpiout9
acpivga0: unknown output device acpiout10
acpivga0: unknown output device acpiout11
acpivga0: unknown output device acpiout12
acpivga0: unknown output device acpiout13
acpivga0: unknown output device acpiout14
acpivga0: connected output devices:
acpivga0:   0x0400 (acpiout0): Int. Digital Flat Panel, index 0, port 0, head 0
acpivga0:   0x0300 (acpiout1): Ext. Digital Monitor, index 0, port 0, head 0, bios detect
acpivga0:   0x0301 (acpiout2): Ext. Digital Monitor, index 1, port 0, head 0, bios detect
acpivga0:   0x0302 (acpiout3): Ext. Digital Monitor, index 2, port 0, head 0, bios detect
acpivga0:   0x0303 (acpiout4): Ext. Digital Monitor, index 3, port 0, head 0, bios detect
PDRC (PNP0C02) at acpi0 not configured
acpiwmi0 at acpi0 (AMW0, PNP0C14-0): ACPI WMI Interface
acpiwmibus at acpiwmi0 not configured
GTPM (IFX0102) at acpi0 not configured
LDRC (PNP0C02) at acpi0 not configured
GEN1 (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43,0x50-0x53 irq 0
pckbc1 at acpi0 (PS2K, TOS7407) (kbd port): io 0x60,0x64 irq 1
pckbc2 at acpi0 (PS2M, TTP1000) (aux port): irq 12
SIRC (PNP0C02) at acpi0 not configured
valz0 at acpi0 (VALZ, TOS6208): Toshiba VALZ
BT (TOS6205) at acpi0 not configured
acpiacad0 at acpi0 (ADP1, ACPI0003): ACPI AC Adapter
acpibut0 at acpi0 (PWRB, PNP0C0C): ACPI Power Button
acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch
acpibat0 at acpi0 (BAT1, PNP0C0A-1): ACPI Battery
acpitz0 at acpi0 (TZ01)
acpitz0: levels: critical 107.0 C, passive cooling
ACPI: Enabled 4 GPEs in block 00 to 7F
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150717/hwxface-646)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150717/hwxface-646)
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pms0 at pckbc1 (aux slot)
pckbc1: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 8086 product 1604 (rev. 0x09)
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 1616 (rev. 0x09)
drm: Memory usable by graphics device = 4096M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
i915drmkms0: More than 8 outputs detected via ACPI
intelfb0: framebuffer at 0xffff80008ed93000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
hdaudio0 at pci0 dev 3 function 0: HD Audio Controller
hdaudio0: interrupting at ioapic0 pin 16
hdaudio0: timeout leaving reset state
hdaudio0: device driver failed to attach
vendor 8086 product 9cb1 (USB serial bus, xHCI, revision 0x03) at pci0 dev 20 function 0 not configured
vendor 8086 product 9cba (miscellaneous communications, revision 0x03) at pci0 dev 22 function 0 not configured
wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x03)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address b8:6b:23:86:df:bb
ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5
ihphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
hdaudio1 at pci0 dev 27 function 0: HD Audio Controller
hdaudio1: interrupting at ioapic0 pin 22
hdafg0 at hdaudio1: vendor 10ec product 0255
hdafg0: DAC00 2ch: Speaker [Built-In]
hdafg0: DAC01 2ch: HP Out [Jack]
hdafg0: ADC02 2ch: Mic In [Jack]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
ppb0 at pci0 dev 28 function 0: vendor 8086 product 9c9a (rev. 0xe3)
ppb0: PCI Express capability version 2  x1 @ 5.0GT/s
ppb0: link is x1 @ 2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
rtsx0 at pci1 dev 0 function 0: vendor 10ec product 5227 (rev. 0x01)
rtsx0: interrupting at msi1 vec 0
sdmmc0 at rtsx0
ppb1 at pci0 dev 28 function 2: vendor 8086 product 9c94 (rev. 0xe3)
ppb1: PCI Express capability version 2  x1 @ 5.0GT/s
ppb1: link is x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
iwm0 at pci2 dev 0 function 0: vendor 8086 product 095a (rev. 0x59)
iwm0: interrupting at msi2 vec 0
ehci0 at pci0 dev 29 function 0: vendor 8086 product 9ca6 (rev. 0x03)
ehci0: interrupting at ioapic0 pin 23
ehci0: EHCI version 1.0
usb0 at ehci0: USB revision 2.0
pcib0 at pci0 dev 31 function 0: vendor 8086 product 9cc3 (rev. 0x03)
ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 9c83 (rev. 0x03)
ahcisata0: interrupting at ioapic0 pin 19
ahcisata0: 64-bit DMA
ahcisata0: AHCI revision 1.30, 3 ports, 32 slots, CAP 0xcf34ff02
atabus0 at ahcisata0 channel 0
isa0 at pcib0
tpm0 at isa0 iomem 0xfed40000-0xfed44fff irq 7: device 0x001a15d1 rev 0x10
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
attimer1: attached to pcppi0
acpicpu0 at cpu0: ACPI CPU
acpicpu0: C1: FFH, lat   1 us, pow  1000 mW
acpicpu0: C2: FFH, lat 148 us, pow   200 mW
acpicpu0: C3: FFH, lat 233 us, pow   200 mW
acpicpu0: P0: FFH, lat  10 us, pow 15000 mW, 2401 MHz, turbo boost
acpicpu0: P1: FFH, lat  10 us, pow 15000 mW, 2400 MHz
acpicpu0: P2: FFH, lat  10 us, pow 14088 mW, 2300 MHz
acpicpu0: P3: FFH, lat  10 us, pow 12607 mW, 2100 MHz
acpicpu0: P4: FFH, lat  10 us, pow 11888 mW, 2000 MHz
acpicpu0: P5: FFH, lat  10 us, pow 11184 mW, 1900 MHz
acpicpu0: P6: FFH, lat  10 us, pow  9680 mW, 1700 MHz
acpicpu0: P7: FFH, lat  10 us, pow  9019 mW, 1600 MHz
acpicpu0: P8: FFH, lat  10 us, pow  7738 mW, 1400 MHz
acpicpu0: P9: FFH, lat  10 us, pow  7119 mW, 1300 MHz
acpicpu0: P10: FFH, lat  10 us, pow  6511 mW, 1200 MHz
acpicpu0: P11: FFH, lat  10 us, pow  5209 mW, 1000 MHz
acpicpu0: P12: FFH, lat  10 us, pow  4643 mW,  900 MHz
acpicpu0: P13: FFH, lat  10 us, pow  4090 mW,  800 MHz
acpicpu0: P14: FFH, lat  10 us, pow  3021 mW,  600 MHz
acpicpu0: P15: FFH, lat  10 us, pow  2386 mW,  500 MHz
acpicpu0: T0: I/O, lat   1 us, pow     0 mW, 100 %
acpicpu0: T1: I/O, lat   1 us, pow     0 mW,  88 %
acpicpu0: T2: I/O, lat   1 us, pow     0 mW,  76 %
acpicpu0: T3: I/O, lat   1 us, pow     0 mW,  64 %
acpicpu0: T4: I/O, lat   1 us, pow     0 mW,  52 %
acpicpu0: T5: I/O, lat   1 us, pow     0 mW,  40 %
acpicpu0: T6: I/O, lat   1 us, pow     0 mW,  28 %
acpicpu0: T7: I/O, lat   1 us, pow     0 mW,  16 %
coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=105
acpicpu1 at cpu1: ACPI CPU
acpicpu2 at cpu2: ACPI CPU
coretemp1 at cpu2: thermal sensor, 1 C resolution, Tjmax=105
acpicpu3 at cpu3: ACPI CPU
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
ERROR: 2866 cycle TSC drift observed
acpiacad0: AC adapter online.
IPsec: Initialized Security Association Processing.
uhub0 at usb0: vendor 8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ahcisata0 port 0: device present, speed: 6.0Gb/s
wd0 at atabus0 drive 0
wd0: 
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 238 GB, 496149 cyl, 16 head, 63 sec, 512 bytes/sect x 500118192 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA)
uhub1 at uhub0 port 1: vendor 8087 product 8001, class 9/0, rev 2.00/0.03, addr 2
uhub1: single transaction translator
uhub1: 8 ports with 8 removable, self powered
uhub2 at uhub1 port 6: vendor 05e3 USB2.0 Hub, class 9/0, rev 2.10/88.30, addr 3
uhub2: single transaction translator
uhub2: 4 ports with 0 removable, self powered
uvideo0 at uhub1 port 7 configuration 1 interface 0: Chicony Electronics Co.,Ltd. TOSHIBA Web Camera - FHD, rev 2.00/83.73, addr 4
video0 at uvideo0: Chicony Electronics Co.,Ltd. TOSHIBA Web Camera - FHD, rev 2.00/83.73, addr 4
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio1 at pad0: half duplex, playback, capture
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
kern.module.path=/stand/amd64/7.99.24/modules
iwm0: hw rev: 0x210, fw ver 25.228 (API ver 9), address 5c:e0:c5:a8:88:ab
iwm0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwm0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwm0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wsdisplay0: screen 1 added (default, vt100 emulation)
wsdisplay0: screen 2 added (default, vt100 emulation)
wsdisplay0: screen 3 added (default, vt100 emulation)
wsdisplay0: screen 4 added (default, vt100 emulation)

ディスプレイ

最近のNetBSD 7.0やcurrentでは、DRM/KMSサポートが追加されており、dynabook R63/PSに搭載されているIntelのチップセットでも、それを使用することができます。ですので、コンソール、XともにフルHDの解像度で使用することができます。 ただし、Xにおけるアクセラレーションは有効化することができません。native X.org (/usr/X11R7以下にインストールされるX.org)では、以下のように/etc/X11/xorg.confに設定する必要があります、

Section "Device"
        Identifier  "Card0"
        Option  "NoAccel"
        Driver  "intel"
        BusID   "PCI:0:2:0"
EndSection
NoAccelオプションを指定する必要があると言うことです。

しかし、Firefoxを起動すると、以下のようにエラーが発生しているようです。

drm: stuck on render ring
drm: GPU HANG: ecode 0:0x0fdf9faf, reason: Ring hung, action: reset
drm: GPU hangs can indicate a bug anywhere in the entire gfx stack, including us
erspace.
drm: Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
drm: drm/i915 developers can then reassign to the right component if it's not a kernel issue.
drm: The gpu crash dump is required to analyze gpu hangs, so please always attach it.
drm: GPU crash dump saved to /sys/class/drm/card0/error
i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0)
drm: stuck on render ring
drm: GPU HANG: ecode 0:0x0fdf9faf, reason: Ring hung, action: reset
i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0)
drm: stuck on render ring
drm: GPU HANG: ecode 0:0x0fdf9faf, reason: Ring hung, action: reset
i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0)
drm: stuck on render ring
drm: GPU HANG: ecode 0:0x0fdf9faf, reason: Ring hung, action: reset
i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0)
drm: stuck on render ring
drm: GPU HANG: ecode 0:0x0fdf9faf, reason: Ring hung, action: reset
i915drmkms0: interrupting at ioapic0 pin 16 (pci0@pci:0000:00:02.0)
これは、dynabook R63/PSのチップセットをNetBSDではサポートしていないためのようです。Intelチップセットの世代について理解していませんので、これ以上は言及しないことにします。

外部ディスプレイ接続については、HDMIとVGAが用意されていますが、HDMI出力は使用することができません。Vaip Pro 11でもHDMI接続はできませんでしたので、まだサポートされていないのだと思います。VGA出力は、xrandrを使用しないでもミラーリングされる場合が多いです(詳細を探求できていません)。

オーディオ

内蔵スピーカーによるオーディオ再生については、問題はありません。マイク機能、ヘッドフォン機能については試していません。

ポインティングデバイス

アルプス電気製のトラックパッドとポインティングスティック(アキュポイントと言うらしい)が搭載されていますが、通常のPS/2マウスとしてしか認識されません。 ただし、ポインティングスティックには、物理的に2つに分かれたボタンが用意されていますので、ポインティングスティックを使えば、右クリック、エミュレーションして中ボタンクリックも可能ですので、困ることはないと思います。 Linuxには、アルプス電気製のデバイスのサポートもあるようですので、いずれNetBSDでも使えるようにできればと考えています。

キーボード

キーボードは普通のテンキーなしのJIS配列キーボードです。 ただし、東芝独自のGHCI/SCIという仕組みでイベントが発行されます。 FNキーとFn1キー等の組み合わせがWindowsでは使われますが、仕組みとしては、ほぼ全てのキーとFNキーの組み合わせに対してイベントを設定できるようになっています。 内蔵ディスプレイのオンオフ、内蔵ポインティングデバイスのオンオフについては、valz(4)というデバイスドライバーを書いてサポートするようにしました。NetBSD currentでは使用できます。 本当は、内蔵ディスプレイの輝度の変更をしたかったのですが、これについてはACPIの一般的なコードがうまく働いていないようで、valz(4)からは操作できませんでした。acpivga(4)とかのコードをちゃんと理解しないといけないと考えています。

有線LAN

有線LANポートが内蔵されています。Intel I218 Vというもので、wm(4)として認識されます。非常に安定しています。MSI/MSI-Xを使うようです。

wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x03)
wm0: interrupting at msi0 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address b8:6b:23:86:df:bb

無線LAN(WiFi)

iwm(4)として認識されるのですが、すぐにエラーになって使えなくなってしまいます。Vaio Pro 11にもiwm(4)は搭載されていたのですが、どうだったのか…。 エラーメッセージは以下の通りです。

iwm0: failed to load firmware: 35
821.11a/gのいずれでも同じ状況ですので、send-prくらいはしておこうと考えています。

その他のデバイス

他のデバイスについて、箇条書きにしておきます。

  • SDカードスロットは一度しか試していませんが使えました。
  • USB 3/xhciは、搭載されていますが使えません。USB 2/ehciが使えるので、とりあえずは困りません。
  • 内蔵のUSBカメラはuvideo(4)として使えます。
  • ACPI接続のBluetoothコントローラーは認識できません。

おわりに

NetBSDを動かすために、新し目なマシンを用意するのは結構冒険だと思うのですが、ディスプレイ関係でアクセラレーションが効かない以外には、あまり問題はないマシンだと思います。 いずれ、Bluetoothコントローラー、ポインティングデバイスについては、改善を試みようと思っています。

Python psutilとsysctl(3)について

はじめに

Let's Encryptのベータテストに応募したところ、テストユーザーになることができました。 そこで、証明書の取得方法を調べてみると、Pythonで書かれたクライアントを使って取得することが分かりました。 Pythonで書かれているのだから、クロスプラットフォームなのに違いないと最初は思ったのですが、psutilというモジュールを使っており、これが各プラットフォームに独自のCで書かれたコードをたくさん持っていました。 psutil 3.3.0をNetBSDでだいたい動くようにする中で分かった、NetBSD独自のシステム情報の取得の仕組みを紹介します。

psutilは、ごく最近OpenBSDのサポートが追加されました。また、FreeBSDのサポートは以前からされています。 NetBSDサポートの追加は、この2つのOS用のコードをうまく再利用しつつ進めました。

psutilは、Python System and process Utilitiesの略で、プロセスやシステムの情報をアーキテクチャーによらず統一した方法で呼び出せる仕組みです。
https://pythonhosted.org/psutil/
にドキュメントがあり、実行例も丁寧に記述されています。なので、動作確認も比較的容易です。

NetBSDで動くようにするためのパッチは、
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/py-psutil/patches/
にあります。 こういう類いのプログラムを書く経験がほとんどないので、より良い実装方法がありましたら、教えていただければ助かります。

システムの情報を入手する仕組み

システムの情報をユーザーランドのプログラムが入手するには、カーネルに問い合わせをして教えてもらわなくてはなりません。今回psutilでNetBSDをサポートするに当たって調べたところ、以下の2つの仕組みが用意されているようです。

  • sysctlライブラリー関数
  • kvmライブラリーに定義されている関数類

今回は、sysctlライブラリー関数の方を使っているのですが、私の理解できた範囲で、両方について説明してみます。

sysctlライブラリー関数

sysctlについては、sysctl(3)とsysctl(7)のマニュアルページを読みました。 sysctl関数は、MIB (Management Information Base)と言うintの配列を使って欲しい情報を指定して、情報を入手する仕組みです。情報を設定することもできますが、今回はそのような使い方はしませんでした。

$ man 3 sysctl
と実行してみると、マニュアルページを読むことができます。 実際にMIBに指定するパラメーターはsysctl(7)マニュアルページに記載されていますので、
$ man 7 sysctl
を参照すると、いくぶんかは説明されています。 MIBは、intの配列を定義して例えば以下のように手作業で作って使うこともできますが、sysctl(8)コマンドで使用するような文字列を使って、MIBを生成することもできます。
mib[0] = CTL_KERN;
mib[1] = KERN_FILE2;
mib[2] = KERN_FILE_BYFILE;
mib[3] = 0;
mib[4] = sizeof(struct kinfo_file);
mib[5] = 0;
sysctlnametomib("net.inet6.tcp6.pcblist", mib, &namelen)
ほぼ、sysctl(8)コマンドで指定する文字列でMIBを作れるようです。

kvmライブラリーに定義されている関数

これらは、kvm(3)マニュアルページに解説されています。/dev/mem等を通じて情報にアクセスします。これも情報を設定することもできます。 今回は、kvm(3)マニュアルページに解説されている関数は、結果的には使用しませんでした。なので、例はありません。 実行中のカーネルだけでなく、core等から情報を取得することもできるようなので、役立つ場面もあるかもしれません。

sysctl(3)での実例

psutilにNetBSDサポートを追加するに当たって、sysctl(3)を使いましたが、sysctl(7)の解説だけでは、実例がなく良く分からないこともありました。NetBSDのsrcツリーの中の事例も参照しつつ進めました。

以下には、sysctl(3)を使って、各種の情報を取得していく方法について、記していきたいと思います。 なんとなく、NetBSDに特有なものを記載します。pkgsrc/sysutils/py-psutilだと、psutil/arch/bsd/以下の内容です。

プロセスをPIDで指定して、その実行ファイル名を絶対パスで取得する

NetBSD currentのみですが、以下のようにして取得できます。

mib[0] = CTL_KERN;
mib[1] = KERN_PROC_ARGS;
mib[2] = pid;
mib[3] = KERN_PROC_PATHNAME;
mib[3]は、以下のように変えれば、他の情報を得られます。
KERN_PROC_ARGV 引数の文字列
KERN_PROC_ENV 環境変数の文字列
KERN_PROC_NARGV 引数の数
KERN_PROC_NENV 環境変数の数
と、ここまで書いて気付きましたが、psutil_get_cmd_args()は書き方が最適ではないですね。KERN_PROC_NARGVを使えば良いでしょうね。

psutilで使っている箇所は以下です。

PyObject *
psutil_proc_exe(PyObject *self, PyObject *args) {
    pid_t pid;
    char pathname[MAXPATHLEN];
    int error;
    int mib[4];
    int ret;
    size_t size;

    if (! PyArg_ParseTuple(args, "l", &pid))
        return NULL;

    mib[0] = CTL_KERN;
    mib[1] = KERN_PROC_ARGS;
    mib[2] = pid;
    mib[3] = KERN_PROC_PATHNAME;

    size = sizeof(pathname);
    error = sysctl(mib, 4, NULL, &size, NULL, 0);
    if (error == -1) {
        PyErr_SetFromErrno(PyExc_OSError);
        return NULL;
    }

    error = sysctl(mib, 4, pathname, &size, NULL, 0);
    if (error == -1) {
        PyErr_SetFromErrno(PyExc_OSError);
        return NULL;
    }
    if (size == 0 || strlen(pathname) == 0) {
        ret = psutil_pid_exists(pid);
        if (ret == -1)
            return NULL;
        else if (ret == 0)
            return NoSuchProcess();
        else
            strcpy(pathname, "");
    }
    return Py_BuildValue("s", pathname);
}

プロセスの持つスレッド数を取得する

各プロセスの情報は、kinfo_proc2構造体に格納できます。 /usr/include/sys/sysctl.h に定義がされています。

kinfo_proc2構造体にプロセスIDを指定して情報を格納するには、以下のようなMIBを用意します。pidにプロセスIDを指定します。

mib[0] = CTL_KERN;
mib[1] = KERN_PROC2;
mib[2] = KERN_PROC_PID; // PIDを指定して条件を絞ることを示しています。
mib[3] = pid;
mib[4] = size;
mib[5] = 1;
mib[2]は、以下のように変えれば、絞る条件を変更できます。
KERN_PROC_ALL  絞らない
KERN_PROC_GID  グループID
KERN_PROC_PGRP  プロセスグループ
KERN_PROC_RGID  リアルグループID
KERN_PROC_RUID  リアルユーザーID
KERN_PROC_SESSION セッションID
KERN_PROC_TTY  TTYデバイス
KERN_PROC_UID  ユーザーID
プロセスの持つスレッド数は、p_nlwpsに格納されています。

psutilでの使用例は以下のようです。

int
psutil_kinfo_proc(pid_t pid, kinfo_proc *proc) {
    // Fills a kinfo_proc struct based on process pid.
    int ret;
    int mib[6];
    size_t size = sizeof(kinfo_proc);

    mib[0] = CTL_KERN;
    mib[1] = KERN_PROC2;
    mib[2] = KERN_PROC_PID;
    mib[3] = pid;
    mib[4] = size;
    mib[5] = 1;

    ret = sysctl((int*)mib, 6, proc, &size, NULL, 0);
    if (ret == -1) {
        PyErr_SetFromErrno(PyExc_OSError);
        return -1;
    }
    // sysctl stores 0 in the size if we can't find the process information.
    if (size == 0) {
        NoSuchProcess();
        return -1;
    }
    return 0;
}

PyObject *
psutil_proc_num_threads(PyObject *self, PyObject *args) {
    // Return number of threads used by process as a Python integer.
    long pid;
    kinfo_proc kp;
    if (! PyArg_ParseTuple(args, "l", &pid))
        return NULL;
    if (psutil_kinfo_proc(pid, &kp) == -1)
        return NULL;
    return Py_BuildValue("l", (long)kp.p_nlwps);
}

プロセスの持つファイルディスクリプター数を取得する

開かれているファイルに関する情報は、kinfo_file構造体に格納して参照します、 例えばあるプロセスの開いているファイルディスクリプターの数を取得するには、以下のようなMIBを用意します。

mib[0] = CTL_KERN;
mib[1] = KERN_FILE2;
mib[2] = KERN_FILE_BYPID; /* 
mib[3] = (int) pid;
mib[4] = sizeof(struct kinfo_file);
mib[5] = 0;
この結果として得られたkinfo_file構造体の配列の長さが、あるファイルの開いているファイルディスクリプターの数になります。

プロセスのソケットの情報を取得する

Let's Encryptは、psutilのnet_connectionsというメソッドを使っています。これは、netstat(1)やsockstat(1)のような機能で、システムの全てのソケット接続の状況をプロセスごとに取得するものです。 NetBSDのsysctlでは、直接このような機能はないようです。 そこで、sockstat(1)のソースコードを参考にして、kinfo_proc2とkinfo_fileの2種類の構造体を組み合わせることにしました。kinfo_porc2のki_sockaddrとlkinfo_fileのki_fdataが同じ内容を指しているので、その関係を使って結び付けました。

実例は、 http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/py-psutil/patches/patch-psutil_arch_bsd_netbsd__socks.c?rev=1.1&content-type=text/x-cvsweb-markup を参照してください。

おわりに

psutilのLinux用のコードは、多くがprocfsからの情報を使っています。BSDとの思想の違いは、こういう所にもあるのかもしれません。

QEMU Contribute/SubmitAPatch

とりあえず、誤訳もあるだろうが、読んでみたので、掲載しておく。

http://wiki.qemu.org/Contribute/SubmitAPatch

Edition: 22:04, 8 October 2015 Jsnow
Licensed under GNU Free Documentation License 1.2.

貢献/パッチを提出する

QEMUは(バグの修正であれ新しい機能の追加であれ)コードの貢献を歓迎しています。 しかし、私たちはたくさんのパッチを受け取っており、パッチを提出するためのガイドラインを用意しています。 これらに従うことによって、私たちのコードレビューを容易にし、より早くあなたのパッチがコミットされることになります。

全てのQEMUへの貢献は、qemu-develメーリングリストに「パッチとして送られ」なくてはいけません。パッチの貢献は、バグトラッカーにポストしたり、フォーラムにポストしたり、外部にホストしてそのリンクを送ったりしてはいけません。

メーリングリストにポストするのに、購読する必要はありません(メーリングリストのポリシーとして、CCを全て保持し、購読していない人が始めたスレッドに入り続けられるように、全員に返信することになっています)。 購読するならば、配信されてくる電子メールが非常に多いのを覚悟してください。一週間に100通を越えることがよくあります。 メーリングリストはモデレートされています。ある電子メールアドレスからの最初のポストは(購読しているにしろ、していないにしろ)、モデレーターがあなたの電子メールアドレスをホワイトリストに追加するまでしばらく時間がかかります。

パッチの書き方

英語を使う

正しい英語であれば助かります。 もし不安があるならば、codespell等のプログラムを、コードと文書の中の最も一般的な綴りの間違いを見つけるのに使ってください;

QEMUのコーディングスタイルを使う

私たちのコーディングスタイルに従っているか確認するために、提出する前に、「scripts/checkpatch.pl <パッチファイル>」を実行してください。 特にCプリプロセッサーが絡む場合には、checkpatch.plが絶対正しいと言うことはありません。常識も使ってください。

以下も参照してください。

最新のgit masterに対するパッチにする

QEMUのリリースバージョンに対してのパッチを提出することに意味はありません。開発は進んでおり、そのパッチがmasterに適用できるとは限らないからです。 私たちは、選ばれたバグ修正のみをリリースブランチに適用しており、masterに取り入れられたコードのみをバックポートしています。

長いパッチは分割する

長いパッチは、論理的に正しいコードの変更からなるパッチ連続として分割してください。 それぞれの変更は、コンパイルでき、実行できなくてはなりません。 例えば、1つ目のパッチでMakefileにファイルを追加し、2つ目のパッチでそのファイル自体を追加すると言った形式は認められません(このルールは、後ほどgit bisectのようなツールを使う場合に、あるバグを追っている時に、そのバグ以外の問題でQEMUが動かないと言うことがないようにするためです)。 文書は最初にしてください。最後にしてはいけません。と言うのは、誰かが一連のパッチを読む際に、文書をクリーンルームで評価し、コードと文書が一致しているかを確認することができるようにするためです。 コミットメッセージで「Also, ...」と書かれているのであれば、複数のパッチに分割できると考えてください。 適切に分割されたパッチと、良いコミットメッセージを書くことについてのアドバイスとしては、OpenStackのアドバイスを参照してください。

コードの移動を伴うパッチはレビューしやすくする

一連のパッチが大規模なコードの移動を必要とする場合には、そのリファクタリングのレビューを簡単にするコツがあります。 意味が変わる変更(あるいは、関数の名称変更も)は、本来の別の一つのパッチにし、コードの移動の部分とは分けておきます。 一時的に、git config diff.renames true; git config diff.algorithm patienceを使ってください。 「diff.renames」プロパティーにより、ファイル名変更のパッチは、古いファイルを削除して新しいファイルを追加するのではなく、ファイル名変更に特化したコンパクトな表現になります。 また、「diff.algorithm」プロパティーにより、元のファイルの}の行を別の変更された塊であるとして扱うことにより、連続しない一部分を古いファイルから新しいファイルに移す際に分かりにくさを低減させることができます。

コードの移動のパッチは以下のようにしてレビューに回されるのが理想的です。

git format-patch --stdout -1 > patch;
diff -u <(sed -n 's/^-//p' patch) <(sed -n 's/^\+//p' patch)
これにより、大規模なコードの移動ではない一部の変更に着目することができます。

無関係な変更を含まない

特に伝えておきたいこととして、体裁を整えたり、コーディングスタイルを変更したり、ホワイトスペースの変更を、パッチが変更しないコードについて変更しないでください(あなたの変更しているコードのコーディングスタイルの問題を数行修正するのは問題ありません)。 もし、ある程度の大きさ部分のコードが本当に字下げを変更されたり、大規模なスタイルの修正されたりする必要があるのであれば、意味の変更のない変更として、別のパッチの形で提出してください。

QEMUのあまり変更されない部分についての小さなパッチは、重要ではないパッチのためのプロセスを使うことを検討してください。

意味のあるコミットメッセージを書く

コミットメッセージは意味があるように書かれるべきであり、歴史的な記録として、なぜどのあなたの変更が必要であるか、あるいは、有用かを明示するようにしてください。

QEMUは、一般的なgitのコミットメッセージの標準に従っています。つまり、1行目(これは、電子メールの件名になります)は、「サブシステム: 変更の1行でのまとめ」とします。 「変更の1行でのまとめ」は、大文字で始め、再度には「.(ピリオド)」を付けません。 git short-log 30を見て、例として件名はどのようになっているか確認してください。 2行目は空行です。3行目からはパッチの詳細についての説明を記載し、空行を挟んで、Signed-off-by:の行を記載します。 コミットメッセージの本文には、あなたの変更が重要である理由を記載してください。 コメントには、「これはこのバグを修正するものである」に類することは書かないでください(こういう内容は、電子メールの「---」の行以下に記載してください。その部分は最終的なコミットメッセージには含まれません)。 コミットメッセージの本文は、読む人の電子メールクライアントが件名を離して表示させたとしても分かるように、独立した文章にしてください(つまり、「... so that」のように件名から文章が続いているのはいけません)。

パッチを提出する

適切なメンテナーをCCに入れる

パッチはTo:メーリングリストとCC:あなたの修正したファイルのメンテナーで送ってください。 MAINTAINERSファイルで、誰がメンテナーを確認できます。 また、scripts/get_maintainer.plを使うことで、あなたの修正したファイルを最も良く変更しているコミッターが分かります。

例えば、

 ~/src/qemu/scripts/get_maintainer.pl -f hw/ide/core.c

添付ファイルとして送らない

パッチは本文中に記載し、レビューコメントを返信しやすいようにしてください。添付ファイルとして送ってはいけません。

git format-patchを使う

正しい差分の形式を使ってください。 git format-patchは、正しい形式のパッチを含んだ電子メールを生成します(どのように動くのか文書を確認してください)。 git send-emailでメーリングリストに送る前にカバーレターを変更することができます。 (私たちはgit send-emailを使うことを勧めています。なぜかと言うと、電子メールクライアントは、長い行を折り返したり、空白を削除したりすることがあるからです。 ディストリビューションによっては、send-emailをデフォルトではインストールしていないことがあります。追加でダウンロードしなくてはいけない場合があります。例えば、Fedoraベースのシステムでは、git-emailをインストールします) 一連のパッチにはカバーレターが必要です。カバーレターは、スレッドの浅い部分になくてはなりません(全ての一連のパッチは、カバーレターへの返信であり、パッチ間の返信であってはなりません)。一つの独立したパッチは、カバーレターを必要としません(あえてカバーレターを使う場合には、--numberedを使い、カバーレターとパッチを件名で見分けられるようにしてください)。 パッチは見付けやすいように新しくトップレベルのスレッドで送信してください。他の既存のスレッドに返信して、埋もれさせてはいけません。

パッチの電子メールはSigned-off-by:行を含まなくてはならない

詳しくは、SubmittingPatch 1.12を参照してください。 これは必須であって、これがなければあなたのパッチを受け入れることはできません。 別名や頭文字ではなく、本名を使うようにしてください。

意味のあるカバーレターを含める

レビュアーはレビューを始めた段階ではあなたのゴールを分かっていません。まだ文脈を十分に共有していないのです。一連のパッチの最後を見るまで、意味のある変更であると理解できないかもしれません。 ゴールが不明確である一覧のパッチは、レビュアーが十分に考えられないため、レビューと修正のサイクルの数を増加させる恐れがあります。 レビュアーとあなたの両方の利益のため、ゴールをカバーレターで説明するのです。 そうすることで、パッチはよりスムースにレビューされ、より早くマージされます。 カバーレターには、一連のパッチと通してのdiffstatを含めるのを忘れないでください。レビューをしようとする人があなたのカバーレターをチェックすることで、レビュアーが関心を持っているファイルを一連のパッチが変更しているかどうかを確認することができます。

必要であればRFCタグを使う

例えば、「[PATCH RFC v2]」のようにします。 git format-patch --subject-prefix=RFCが便利です。

「RFC」は、「Request For Comments(コメントを希望)」を意味し、あなたのパッチがmasterにそのまま適用されることを意図していないが、レビューして欲しいと言うことを示しています。

このようなことをする理由には以下のようなものがあります:

  • そのパッチが一旦保留されているOSのカーネルの変更に依存しているので、まだQEMUには取り入れて欲しくないが、レビューをする意味はある場合
  • パッチはまだ完成していないが(全ての使用事例を網羅していないとか、全てのターゲットで完了していないとか)、影響の大きいAPIの変更や設計について、先に勧める前にレビューを受けたい場合

この場合、一般的に、レビューされた内容はそのままコミットされないので、以下のようであるのが最良です:

  • 慎重に使用する
  • カバーレターでなぜパッチがRFCなのか、どの分野でレビューして欲しいのか、レビュアーがなぜレビューすべきかのかを明確にする

コードレビューに参加する

全てのQEMUプロジェクトに提出されたパッチは、受け入れられる前に必ずレビューのプロセスを通過します。 良くメンテナンスされている分野のコードは、速やかにレビューされますが、あまりメンテナンスされていない分野では遅れがちです。

コードレビューで発覚した問題を修正し続ける

そのままでQEMUに取り込まれるパッチは多くはありません。開発者がバグを発見したり、より明確なアプローチを示唆されたり、コードスタイルの問題を指摘されたり、コミットメッセージの誤字脱字を指摘されると言ったとこてぁ、極めてよくあることです。 あなたは、このような指摘に応える必要があります。そして、問題を修正した第2版のパッチを送る必要があります。 これは、あなたの側の時間と苦労を伴いますが、これをしなくては、QEMUにあなたの変更が取り込まれることは決してありません。 これは、礼儀正しくあるということでもあります。あなたのコードをレビューし、改善を示唆するのに時間を費した開発者は、あなたがそれ以上に何かをしないのであれば、時間を浪費したと言うことになり、たいへんがっかりさせられます。

あなたのパッチへのコメントに返信する際には、全員に返信し送信者のみに返信しないようにしてください。全ての議論をメーリングリストに残しておくことで、全員がその内容を参照することができます。

レビューコメントに注意を払う

誰かがその時間をあなたのコードを。レビューするのに使ってくれたのです。その努力には敬意を払うべきです。以前にもらったレビューの内容を反映させることなく一連のパッチを投稿し続けることは、レビュアーを遠退かせ、あなたのパッチが行き詰まることを意味します。 レビュアーは常に完璧であるとは限りません。ですので、レビュアーによる要求を全て盲目的に受け入れるのではなく、あなたのコードが正しいと主張することができます。 一方で、誰かがレビューの過程であなたのコードに潜んでいる問題を指摘したが、結局あなたのコードが正しかったとします。そのような場合には、コミットメッセージや。コメントを修正し、なぜあなたのコードが正しいか説明するようにしてください。

もしレビューの過程で浮かび上がった問題を修正したら、それを修正した1つのパッチを投稿するのではなく、一連の全てのパッチを再送信するようにしてください。 これによりメンテナーは手動でどのパッチが適切であるかを判別することなく、簡単に修正された一連のパッチを適用させることができます。 新しいバージョンは完全に新しい電子メールあるいは一連の電子メールで送ってください。バージョン1に返信しようとするのは止めてください(こうすることにより、自動化されたパッチ電子メール取り扱いツールがv1とv2の電子メールを判別できるのを助けます)。

パッチを再送信する場合にはバージョンタグを付加する

最初のバージョン以外の全てのパッチはバージョンタグを含む必要があります。例えば、「[PATCH v2]」のようにします。 これにより、誰もが最新バージョンを簡単に見分けることができるようになります。 (最初のバージョンは「v1」を付ける必要はありません。「[PATCH]」で十分です。) 一連のパッチにおいては、バージョンは一連のパッチの全てに付加される必要があります。一つのパッチのみが変更されたとしても、全てのパッチに「v2」を付加して再送信する必要があります。 1つの一連のパッチで違ったバージョンを付けようとしないでください。 git format-patchとgit send-emailのいずれも-v2オプションを使うことで、これらを簡単に実施することができます。 新しいバージョンをそれぞれ新しいトップレベルのスレッドとして送信してください。以前のバージョンに返信して、埋もれさせてはいけません。多くのレビュアーがスレッドに深く潜らないと新しいパッチを見付けられないようではいけません。

パッチ間の履歴を含める

第2版以降のパッチには、以前のバージョンからの変更のまとめを含めるようにしてください。しかし、コミットメッセージに含めてはいけません。 パッチの電子メールにおいて、「---」の行より上のみがコミットメッセージになりますので、ここのみがコミットされた再にgitの変更履歴となります。 この部分は、このバージョンのパッチが何をしているのかと言う自己完結的な説明でなくてはなりません。6カ月後に見直しても誰もが分かるように書かれなくてはなりません。 「---」の下でパッチ自体の上の行は、(git format-patchはdiffstatをここに挿入しますが)パッチを読んでくれる人に向けての意見を記載するのに良い場所です。「以前のバージョンからの変更点」はここに記載します。 git-publishスクリプトは、各バージョン間のまとめを追うのに便利です。 また、git-backport-diffスクリプトは、バージョン間の変更に着目しているレビュアーに役立ちます。

コツ

Reviewed-by:タグを適切に使うことでレビューを助ける

長い一連のパッチをレビューする時、レビュアーはいくつかのパッチにReviewed-byタグを付けて返信することができます。これは、そのパッチは独立して扱って良いことを示します(ホワイトスペースの変更のようなコードの文脈に影響しない重要でないクリーンアップなど)。 そのような返信を受け取ったら、Reviewed-byタグを手動でコミットメッセージに含め、パッチを次のバージョンにし、レビュアーがどのパッチは既にレビュー済みであるかが分かるようにします。

逆に、以前にレビューを受けたパッチを大幅に変更した場合には、Reviewed-byタグをコミットメッセージから削除し、以前のバージョンからの変更点を記載します。これによって、あなたの変更にレビュアーが注意を簡単に払えるようにします。

あなたのパッチが無視されているような場合

もしあなたのパッチが何の返信ももらえない場合には1から2週間後に「ping」を送るべきです。これは、パッチの電子メールに返信して電子メールを送ることによって行ないます。内容は、「ping」とパッチへのpatchworkまたはGMANEのページへのリンクです。 なぜ無視されているのかを再度見直すのも大切です(メンテナーをCCに入れていないとか、以前のバージョンのレビューコメントに返信していないとか)。ですが、あまりメンテナンスされていない分野では、単に見過されている可能性があります。 pingしても無視されたら、1週間後に再度pingします。 あなたは、あなたのパッチが適用されることに対して最もやる気のある人です。粘り強くなくてはなりません。

私のパッチが適用される時

メーリングリストであなたのパッチが十分にレビューされた後、その分野のメンテナーはメーリングリストにあなたのパッチが特定の準備用のブランチに適用した旨の連絡をします。 定期的に、メンテナーはqemu mainlineにトピックブランチを集約するためのプルリクエストを送ります。 あなたがある分野のコードのメンテナーになるまで、プルリクエストを送る必要はありません。 メンテナーは、あなたのコミットをさらに変更することがあります。単純なマージ時の競合を解決するものである場合や、レビュー中に指摘された重要でない誤字脱字の修正をする場合がありますが、Signed-off-by行があなたの行に追加されます。そのメンテナーのツリーを通じて取り入れられたことを示すためです。 メンテナーのプルリクエストが難しいマージ時の競合に遭遇することがあります。このような場合には、リベースト問題の解決を手助けして欲しいと依頼されるかもしれません。 あなたのパッチが最初に良い返事をもらってからqemu.gitに含まれるようになるまで、数週間は必要かもしれません。リリースサイクルフリーズに期間に重なると、もっと長くかかるでしょう。

敬意を返す

ピアレビューは全ての人がレビューに時間を割く場合のみ成立します。 もし全員が自分のレビューするよりも多くのパッチを提出するとしたら、パッチは停滞します。 良いゴールは、自分が提出したのと同じ数だけ他の人のパッチをレビューすると言うことです。 メンテナーほどコードベースに詳しくないからと言って心配しないでください。あなたがコードにあまり親しんでいなことにより、レビューが弱いと言うのは、完全に許されています。

TOPPERS/FMPをqemu-system-arm -M vexpress-a9で動かす

pkgsrc/cross/arm-none-eabi-binutilsとarm-none-eabi-gcc5と言うパッケージを作っていて、これらが正しいバイナリーを生成してくれるか試したいと思っていた。
と同時に、一度リアルタイムオペレーティングシステムと言うのを試してみたいとも思っていた。
そこで、arm-none-eabi-*を使ってビルドすることになっているTOPPERS kernelを試してみることにした。ビルドしたら、そのバイナリーが正しく動作するか確認しないといけない。私はRaspberry PiとCubieboard 2を持っているのだが、TOPPERS/JSP、TOPPERS/ASP、TOPPERS/FMPともに、これらのボードには移植されていないようである。
Skyeye のARMエミュレーション用に移植されているのだが、どうやらCodeSourcery Liteが必要らしく、CodeSourcery Liteは既に無料で配布されていないし、それをNetBSDで動かすのも面倒に違いないので、Skyeye用は試すこともしなかった。
エミュレーターと言えばqemuと思って検索してみると、TOPPERS/FMP kernelは、qemu 1.3.0にパッチを当てたものに移植されているらしい。
https://www.toppers.jp/fmp-e-download.html
に、QEMU Versatile Express Cortex-A9 (4 cores)簡易パッケージとして、TOPPERS/FMP 1.2.2が掲載されている。
TOPPERS/FMPの最新版は1.3.0なので、最新版でないのは少し引っかかるが、試してみることにした。

まず、TOPPERS新世代カーネル用コンフィギュレーターと言うものをビルドしないといけないらしい。

https://www.toppers.jp/cfg-download.html

によると、最新版は1.9.4なので、それを試してみることにした。
Makefile中でGNU makeをmakeとして呼んでいるので、そこを$(MAKE)に変更すれば、NetBSD/amd64 currentでも他には修正は必要ない。
パッチは、

https://www.toppers.jp/TOPPERS-USERS/2015-October/004251.html

に投稿しておいた。
pkgsrcからboostをインストールしてある場合には、以下のようにしたら良い。
$ tar zxvf cfg-1.9.4.tar.gz
$ cd cfg
$ ./configure --with-libraries=/usr/pkg/lib --with-headers=/usr/pkg/include
$ patch < diff
$ gmake LDFLAGS=-Wl,-R/usr/pkg/lib

$ tar zxvf fmp_vexpressa9_gcc-20121214.tar.gz
$ cd fmp
$ cp ../cfg/cfg cfg/
$ mkdir build
$ perl ../configure -g ../cfg/cfg/cfg -T vexpressa9_gcc
$ PATH=/usr/pkg/cross-arm-none-eabi/bin:${PATH} gmake ENABLE_G_SYSLOG=false PRC_NUM=4 KERNEL_FUNCOBJS=

fmpというのが、kernelとサンプルアプリケーションが含まれたものになるので、それを実行してみる。

$ qemu-system-arm -cpu cortex-a9 -M vexpress-a9 -smp 4 -serial vc:80Cx40C -serial vc:80Cx40C -serial vc:80Cx40C -serial vc:80Cx40C -no-reboot -icount auto -m 1024M

表示されたGUIの画面で、Ctrl+Alt+4から7を入力することで、タイマー動いているのを確認することができる。
これには、qemu 1.3.0にパッチを当てたものを使用したのだが、qemu 2.4.0.1に替えてみると、タイマーが動き出さず、しばらくしたらメインメモリーアクセスの違反でcore dumpしてしまう。

qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000

このエラーメッセージで検索してみると、
http://blog.3mdeb.com/2014/08/07/debugging-coreboot-for-qemu-armv7-vexpress-a9-emulated-mainboard/
で同じ問題が解析されている。
私の場合はどうかとqemuで、実行している命令をダンプしてみると、以下のようになっている。-d in_asmをqemu-system-armの引数として加えると、実行している命令をディスアセンブルして表示できる。
----------------
IN:
0x6000591c:  e5901014      ldr  r1, [r0, #20]
0x60005920:  e5801010      str  r1, [r0, #16]
0x60005924:  e3510000      cmp  r1, #0  ; 0x0
0x60005928:  0a000001      beq  0x60005934

----------------
IN:
0x6000592c:  e591d018      ldr  sp, [r1, #24]
0x60005930:  e591f01c      ldr  pc, [r1, #28]

----------------
IN:
0x60005984:  e32ff013      msr  CPSR_fsxc, #19  ; 0x13

----------------
IN:
0x00000018:  00000000      andeq        r0, r0, r0
0x0000001c:  00000000      andeq        r0, r0, r0

(snip)

0x03fffff8:  00000000      andeq        r0, r0, r0
0x03fffffc:  00000000      andeq        r0, r0, r0

qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000

R00=6004d314 R01=6004e15c R02=00000001 R03=6004d314
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=60033994
R12=600000d3 R13=00000000 R14=6000598c R15=04000000
PSR=00000192 ---- A irq32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000

どうやら、アドレス0x000000018に何らかの理由でジャンプしたらそこが0で埋められていて、それを順々に実行して、0x04000000に到達してエラーでcore dumpしていることが分かった。
では、0x000000018に何があるのかと言うと、0x60000018がマッピングされていることが想定されていて、irq_vectorと言うのがあると期待されている。これは、
$ arm-none-eabi-objdump -D fmp
fmp:     file format elf32-littlearm


Disassembly of section .text:

60000000 <__text>:
60000000:       e59ff018        ldr     pc, [pc, #24]   ; 60000020 <_kernel_vector_ref_tbl>
60000004:       e59ff018        ldr     pc, [pc, #24]   ; 60000024 <undef_vector>
60000008:       e59ff018        ldr     pc, [pc, #24]   ; 60000028 <swi_vector>
6000000c:       e59ff018        ldr     pc, [pc, #24]   ; 6000002c <prefech_vector>
60000010:       e59ff018        ldr     pc, [pc, #24]   ; 60000030 <data_abort_vector>
60000014:       e59ff004        ldr     pc, [pc, #4]    ; 60000020 <_kernel_vector_ref_tbl>
60000018:       e59ff014        ldr     pc, [pc, #20]   ; 60000034 <irq_vector>
6000001c:       e59ff014        ldr     pc, [pc, #20]   ; 60000038 <fiq_vector>

60000020 <_kernel_vector_ref_tbl>:
60000020:       6000003c        andvs   r0, r0, ip, lsr r0

60000024 <undef_vector>:
60000024:       60003c68        andvs   r3, r0, r8, ror #24
(snip)

で確認することができる。

さきほどのウェブサイトによると、

http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101111fc7f0

によって、0x60000000が0x00000000にマッピングされなくなっているらしい。
そう言うことであれば、割込みベクターの位置を0x60000000にすれば良いと考えられる。

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388fj/CIHGDDEI.html

にあるVBARレジスターを0x6000000に設定すれば良いように見える。

vexpressa9_gccターゲットをTOPPERS/FMP 1.3.0に移植し、qemu 2.4.0.1で動くようにしたソースコードを、

https://github.com/ryo-on/toppers-fmp-for-qemu-vexpress-a9

に置いておいた。
しかし、VBARの部分は、移植性を無視した形になっているので、他の方法を考えないといけないように思う。

とりあえず、pkgsrc/cross/arm-none-eabi-*が正しいバイナリーを生成していそうであるのは確認できたので良いことにする。

Vaio Pro 11のACアダプターの追加購入

Vaio Pro 11のACアダプターを持ち忘れてしまうことが多いので、もう一台を検討してみた。

正規版は、https://vaio.com/products/acc/VJ8AC10V9/ にあるVJ8AC10V9な訳だが、ソニーストアで扱ってもらえるようになって、買えないと言う状態ではなくなったが、6,980円は結構な出費になる。
そこで、秋葉原で中古ACアダプターを扱っている店をいくつか探してみた。
まず、VJ8AC10V9については、中古品は見付けられなかった。その他のソニー製の10.5VのACアダプターも見当たらない。同じ10.5Vのものも、見付けられない。しかし、10VのものはNECの製品がいくつか出品されていた。
最終的には、ショップインバース http://www.shop-inverse.net/ でNEC製PC-VP-BP72を1,500円で購入した。これは、10V 4AのACアダプターである。無事に使用できた。DC側のコネクターの形状も問題ない。
他にも4A以上のNEC製のACアダプターも売られていたが、大きさが小さいものがよかったので、PC-VP-BP72にした。
手軽に買えると言う点では、以前に記事を書いたように、Amazon.co.jpで買うのが良いのだろうが、実店舗で買う方が半額程度になる結果となった。

Windows 7 Professional用のNFSクライアントを使う (NFS 4.1のみ)

Windows 7 Professional 32-bitなマシンがある。
NFSをマウントするには、Services for Unix (SFU)を使うのが定石なのだと思うが、ProfessionalにはSFUは用意されていない。
調べてあると、
http://citi.umich.edu/projects/nfsv4/windows/
にNFSクライアントがLGPLv3で公開されている。
しかし、Gitサーバーは既に機能していないようだ。

https://github.com/kofemann/ms-nfs41-client
に、リポジトリーがミラーされていて、README.mdが整備されている。
https://github.com/kofemann/ms-nfs41-client/blob/master/README.md
基本的にこれに従えば良いが、つまずいた箇所を書いておく。

これを、
https://msdn.microsoft.com/en-us/library/windows/hardware/ff557573%28v=vs.85%29.aspx
からリンクされている、Windows Driver Kit 7.1.0
https://www.microsoft.com/en-us/download/details.aspx?id=11800
を使って、Visual C++ 2010 Expressでビルドしてみる。
まず、README.mdにあるように、build.vc10\env.prop.exampleをenv.propと言うファイル名にコピーし、Windows Driver Kitのディレクトリー名を、実際の値に合わせてやる。今回の場合は、C:\WinDDK\7600.16385.0になっていたものを、C:\WinDDK\7600.16385.1に書き換えた。

Visual C++ 2010 Expressから、build.vc10\ms-nfs41-client.slnを開いて、daemonプロジェクトをビルドしてみる。

すると、依存するプロジェクトのビルドが始まるが、MFC (Microsoft Foundation Class)の一部である、afxres.hが見付からないいと言うエラーでlibtirpcプロジェクトがビルドできない。
これは、ms-nfs41-client\libtirpc\libtirpc\libtirpc.rc中の2箇所のafxres.hをwindows.hに置き換えてやれば良いようだ。

あとは、makecertしたら、nfs41-client.cerを信頼された証明書発行機として、追加してやることが必要になる。

そして、ちゃんと動いたかと言う話になるが、NFSサーバーはNetBSD 6で、NFS 4.1に対応していないので、結局動作確認はできなかったのであった。

Visual C++ 2010 Expressで、LNK1123エラーが出てビルドが完了しない場合

Windowsでのプログラミングも、C++も分からないのだが、Visual C++ 2010用の小さなプログラムをビルドする用事があって、Visual C++ 2010 Expressをインストールした。
ビルドしてみたのだが、「LNK1123: COFFへの変換中に障害が発生しました」とエラーが出て、リンクが完了しない。
Visual Studio 2010 SP1と言うのが、Expressにも適用できるようで、Windows Updateからインストールしたら、このエラーは出なくなった。

QNX 6.5をVMware ESXi 5.5上にインストールする

2011年の3月に、QNX 6.5のNon-commercial licenseを取得して、pkgsrcでしばらく遊んでいた。
その時には、VMware PlayerかVirtualBoxかを使っていたのだと思うのだが、今は、VMware ESXiを使っている。

QNX 6.5のインストールイメージは、

http://www.qnx.com/download/group.html?programid=20905

からbootableなものをダウンロードしてくれば良いのだが、今はNon-commercial licenseの配布はしていないようにも見える。

ところで、VMeware ESXiは、標準では、SCSIの仮想ハードディスクを提供してくれるのだが、QNX 6.5では、BusLogicのコントローラーにしても、認識してもらえない。

http://www.qnx.co.jp/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.momentics_release_notes%2Frel_6.5.0.html

によると、Updating disk driverというのを実行すれば良いらしいのだが、私の知識では、ディスクドライバーをアップデートすることはできなかった。

http://virtuallyfun.superglobalmegacorp.com/2014/07/21/using-ide-hard-disks-on-vmware-esxi-5-5/

によると、仮想マシンの作成時にオペレーティングシステムとしてOS/2を選んでおけばIDEのハードディスクが提供されるらしい。QNX 6.5のようにIDEが必要な場合には、OS/2を選ぶのを忘れないようにしないといけない。まあ、64ビットでIDEが必要になった場合には困るけれども。

最近のSafari Books Onlineのこと

Safari Books Onlineというサービスがあって、英語の技術書であれば、結構いろいろな書籍を定額で参照できる。
https://www.safaribooksonline.com/

2010年とか2012年ころに、日本語話者で使っている人はいたようだが、最近の様子を書いている人はいないようなので、書いておく。

私が使い始めた2014年には個人向けにはBookshelfとLibraryというコースがあったのだが、2015年5月1日現在は、個人向けにはProというコースだけのようである。
Bookshelfの契約者には、Pro相当へアップグレードできるオファーがあったので、その頃に変わったのだと思う。
いずれにしても、今は、個人ではPro以外の選択肢はないようだ。

読める書籍については、O'Reilly以外もあるし、必ずしも計算機科学やソフトウェアの解説書だけではないので、自分で検索してみるか、Free Trialに申し込んでみたら良いと思う。どういう書籍やビデオがあるかの検索は、ログインしていなくてもできる。
昔のSafari Books Onlineについての記事を読むと、PDFファイルとしてダウンロードできたような記述があるが、現在はその機能はない。ただ、私の読んだ全ての書籍は、章ごとにHTMLとなっていて印刷できるので、必要であれば、PDFファイルに変換して持っておけば良いように思う。HTMLとしてダウンロードしておけるかは、試していない。
ビデオはダウンロードできないようだ。

Androidでの閲覧は、ウェブブラウザー以外に、Safari To Goというアプリケーションを使うことができるが、この機能は貧弱なので、あまり便利ではない。唯一価値があるとしたら、3冊を上限として、オフラインで閲覧できることだと思う。
iOSにはもっとちゃんと使えるアプリケーションが用意されているので、早くAndroid版も用意して欲しい。

http://www.oreilly.co.jp/safari/
にO'Reilly Japanが簡単な解説を書いてくれているのだが、Bookshelf/Library時代の解説なので、直して欲しい。

「ホントにゼロからの簿記3級」ふくしままさゆき著 Kindle版

昨日まで、Amazon.co.jpでは、プライム会員向けにKindleの3,000円引きキャンペーンをしていた。
私もそれに乗って購入したのだが、Kindleオーナーライブラリーの機能は、貸し出しエラーが出て使えなかった。
しかし、英語UIにしたりリセットしたりして、貸し出ししてもらえるようになったので、ちょうど目についた標記の書籍を読んでみた。

内容としては、一般の簿記の教科書を補足するような内容であった。簿記特有の良い回しとか、用語について、どれは理解しておかなくてはいけなくて、どれは概念さえ理解して仕訳できれば良いか、説明してあったので良いと思う。
こう言う勘所は、ちゃんと勉強した上でないと、自力では行き着けないので、教えてもらえると助かると思う。

「条文の読み方」法令執務用語研究会著 有斐閣刊

法学と言うのを学びたいと常々思っているのだが、なかなか学ぶ機会がない。
昼の仕事に関連する部分については、嫌でも学ぶことになるのだが、法学一般についてや法学の基本的な考え方については、全く学べていない。

そうであれば、本来はこの本ではないのかもしれないが、用語が分かることは必要であるので、読んでみた。

似たような単語の使い分け等を説明してくれているので、法令を読むのに非常に役立つと思う。でも、覚えておかないといけないので、もう何回か読み直す必要はありそうだ。
それと、これはこの本のせいではないのだが、法令には文脈で解釈しなくてはいけないケースが存在すると言うことが書かれていて、唯一の意味だけに解釈可能にはなっていないのがちょっと不満に思った。

AndroidのK-9 Mail

Androidには、標準でGoogleによる「メール」というアプリケーションがインストールされていて、POP3やIMAP4の電子メールサーバーにアクセスできる。
しかし、SMTPサーバーを指定するのにあまり自由度がない。

Open Sourceで良いものがないか探してみたところ、K-9 Mail
https://play.google.com/store/apps/details?id=com.fsck.k9&hl=en
と言うのが、いろいろ自由に設定できるし、私の要件には合っていた。

まず、SMTPサーバーを自由に設定したかった。これは、K-9 Mailでは自由に設定できる。
次に、フッターに広告が入らないことが望ましかった。有料の電子メールクライアントアプリケーションの無料版では、フッターの広告を消せないものばかりだった。
K-9 Mailも、標準ではK-9 Mailを使っている旨のメッセージが入るが、ちゃんと消すことができる。

他にも、複数アカウントへの対応も可能なのは良い点だと思うが、私は使っていない。

Firefox 37.0.2 for Androidがクラッシュしなくなった

しばらく前から、Firefox for Androidは、すぐにクラッシュして終了してしまうので、使い物にならなくなっていた。
久しぶりにFirefox 37.0.2 for AndroidをPanasonic P-02Eにインストールしたところ、今のところ全くクラッシュしないので、また使い始めることができそうだ。

この問題は、日本語ロケールのAndroidに特有に問題だったのか、全く注意を向けてもらえていなかったように思う。私もbug reportとかしなかったけれども。

Vaio Pro 11/13用のサードパーティーのACアダプター

Vaio株式会社の製造するようになったVaio Pro 11/13だが、総代理店であるソニーストアでは、専用ACアダプターは品切れになっていて購入できない。
また、メジャーなメーカーで互換性のあるACアダプターは現在は製造されていない。

Amazon.co.jpを検索すると、使えそうな物が少なくとも2つ販売されている。
そのうち、レビューのない方を購入してみたので報告する。

前提として、Vaio Pro 11/13のACアダプターは、SONY Vaio type P等のACアダプターの電流値が大きくなったものである(純正品のVJ8AC10V9は、10.5V、3.8Aの出力である)。

まずは購入していない物について述べておく。


これは、レビューを読む限りでは、NEC等の10V出力のACアダプターのプラグ部分を付け替えたもののようである。それはそれでありなのだと思うが、品質にはばらつきがあってもおかしくない。


次に購入したものについて述べる。


これを注文した訳だが、届いたものは、Anthin API324-1024というACアダプターであった。これは、10V、2.4A直流出力のACアダプターである。
データシートも入手できる。

http://www.anthin.co.jp/spec/ST-0229%20%20%20API324-1024.pdf

私は知識が不足しているので、このACアダプターのプラグ部分を改造しているのかを判断することはできない。

この10V、2.4Aの仕様でも充電できたので、問題なく使えると言えそうである。
Amazonプライム対応なので、トータルコストとしては、こちらの方が安くすむ。

他にも、既に販売終了しているが、ELECOM ACDC-SY1036BKと言うVaio type P用のサードパーティーのACアダプターも使えるはずである。これは、10.5V出力らしい。
見かけたら買っておいても良いかもしれない。

http://www2.elecom.co.jp/cable/ac-adapter/acdc-sy1036/

Buffalo WLI-UC-GNM2をMicrosoft Windows 7 Professional 32-bitで使う場合の注意

Buffalo WLI-UC-GNM2は、パッケージを捨ててしまうと、実機に型式が書かれていないので何と言う機械なのか分からなくなってしまう問題がある。
USBのVendor ID/Product ID=0x0411/0x01eeであれば、WLI-UC-GNM2である。

これをWindows 7 Professional 32-bitで使う場合には、必ず、

http://buffalo.jp/download/driver/lan/old/wli-uc-gnm2.html
WLI-UC-GNM2シリーズ設定CD Ver.1.00(2011年8月1日)

からダウンロードできるwliucgnm2-100.exeファイルに入っているデバイスドライバーを使わなければならない。
もっと新しいバージョンがいくつかBuffalo社のウェブサイトでは公開されているが、少なくともWindows 7 Professional 32-bitで使う場合には、それらのデバイスドライバーを正常にインストールできない。

zoho Email hostingで、サブドメインを設定する

zoho Email hostingでは、無料では一つの独自ドメインで電子メールを受信できるようになっている。
しかし、公式サイトの説明では、独自ドメインのサブドメインで受信できるようにする方法が分かりにくかった。
結果としては、CNAME認証をすれば良い。
ウェブサイト認証でも良いが、そのサブドメインを電子メールでのみ使う場合には、適用できないので、お勧めしない。

pkgsrc/pkgtools/libkverを使って、chroot環境のunameを偽る方法

pkgsrc/pkgtools/libkverを使うと、uname -r等を偽ることができる。
これによって、unameの情報を使うプログラムをだまして実行することができる。

pkgsrcのbinary packagesは、uname -sやuname -rを埋め込んでいる。
例えばNetBSD/amd64 current上でchroot環境を用意し、
NetBSD/amd64 6.1用のbinary packagesを作る場合に、libkverを使うことで
他のマシンでpkg_addが可能なbinary packageとすることができる。

こうしないと、NetBSD 6用のlibraryにリンクしているのに、
binary packageとしては、7.99.*用の情報が埋め込まれていて、
pkg_addしにくいbinary packageになってしまう。
また、pkgsrcのMakefileはunameの結果を使って条件分岐する箇所
があるので、buildに失敗するpackagesもあるはずである。

pkgsrc/pkgtools/libkverを使う場合については、

http://comments.gmane.org/gmane.os.netbsd.devel.packages/13587

にあるような手順が書かれているが、手作業でchroot環境を起動させる
場合については、若干分かりにくいように感じたので、手順を書いておく。
ちなみに、pkgsrc/sysutils/sudoを使っていないのは、sudoがLD_*という
環境変数を切り替え先の実行ユーザーに渡さない仕様であるからである。
先にsu(1)でrootになっておく。

(1) chroot環境の外側でlibkverをinstallする。

# cd /usr/pkgsrc/pkgtools/libkver
# make install
# make clean


(2) chrootに一度入り、chroot環境の内側でもlibkverをinstallする。

# chroot /usr/tmp/chroot/netbsd-6/root /bin/ksh
# cd /usr/pkgsrc/pkgtools/libkver
# make install
# make clean
# exit


(3) libkverを使ってchroot環境に入り直す。
ここでは、NetBSD/amd64 7.99.5上で、NetBSD/amd64 6.1に偽る場合を示す。

# kver -r 6.1 chroot /usr/tmp/chroot/netbsd-6/root /bin/ksh
# uname -r
6.1
# uname -a
NetBSD angelcake.elements.tetera.org 6.1 NetBSD 6.1 (LIBKVER) #0: Tue Jan 19 00:00:00 UTC 2038 root@localhost:/sys/arch/amd64/compile/LIBKVER amd64

plgarc/wip/llama.cppでpkgsrcのBLASサポートを探る

この記事は、 NetBSD Advent Calendar 2024 の13日目の記事です。 llama.cppを使ってみる 以前に、 NetBSD/amd64でllama.cppを使ってみる という記事で llama.cpp を使ってみていました。 あれか...