コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2023年2月4日 >>> 2023年1月22日

もっと後

2023年2月4日

permalink

編集する

RISC-V 64bit Linuxとシステムコールと32bitの引数その4 - MAP(), SC_X() マクロの実装

目次: RISC-V

昨日の続きです。「64bit環境においてシステムコールの引数がレジスタ長（= 64bit）以下だった場合（例えばintが典型例）、どう扱うか？」コードの解説編です。

どうして符号拡張されるのか？逆アセンブルで説明したつもりになってはいけない、逃げてはダメだ！という熱心なあなたのために、マクロを展開しながら説明します。今回の解説は __MAP(), __SC_LONG(), __SC_CAST() マクロの意味や実装です。

任意の引数に変換を掛ける __MAP() マクロ

鍵となるのは __MAP(4, ...) の展開後に出てくる __MAP4(m, t, a, ...) というマクロです。

__MAP() マクロの実装


// linux/include/linux/syscalls.h

/*
 * __MAP - apply a macro to syscall arguments
 * __MAP(n, m, t1, a1, t2, a2, ..., tn, an) will expand to
 *    m(t1, a1), m(t2, a2), ..., m(tn, an)
 * The first argument must be equal to the amount of type/name
 * pairs given.  Note that this list of pairs (i.e. the arguments
 * of __MAP starting at the third one) is in the same format as
 * for SYSCALL_DEFINE<n>/COMPAT_SYSCALL_DEFINE<n>
 */
#define __MAP0(m,...)
#define __MAP1(m,t,a,...) m(t,a)
#define __MAP2(m,t,a,...) m(t,a), __MAP1(m,__VA_ARGS__)
#define __MAP3(m,t,a,...) m(t,a), __MAP2(m,__VA_ARGS__)
#define __MAP4(m,t,a,...) m(t,a), __MAP3(m,__VA_ARGS__)
#define __MAP5(m,t,a,...) m(t,a), __MAP4(m,__VA_ARGS__)
#define __MAP6(m,t,a,...) m(t,a), __MAP5(m,__VA_ARGS__)
#define __MAP(n,...) __MAP##n(__VA_ARGS__)

マクロに渡された型tと引数aリストのペアを1つずつm(t, a) のようにmで変換を掛けるマクロですが、イメージしづらいと思うので展開結果を載せます。

__MAP() マクロの展開結果の例


__MAP(4,__SC_LONG,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)

↓

__MAP4(__SC_LONG,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)

↓

__SC_LONG(int, magic1),
__SC_LONG(int, magic2),
__SC_LONG(unsigned int, cmd),
__SC_LONG(void __user *, arg)

実装はぱっと見では良くわかりませんが、展開結果はわかりやすいですね。

キャストの要、__SC_LONG(), __SC_CAST() マクロ

先頭の展開結果 __SC_LONG(int, magic1) に着目します。

__SC_LONG() マクロの実装


// linux/include/linux/syscalls.h

#define __SC_LONG(t, a) __typeof(__builtin_choose_expr(__TYPE_IS_LL(t), 0LL, 0L)) a

#define __TYPE_AS(t, v)	__same_type((__force t)0, v)
#define __TYPE_IS_LL(t) (__TYPE_AS(t, 0LL) || __TYPE_AS(t, 0ULL))


// linux/include/linux/compiler_types.h

#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))

# define __force

ここまでの実装を踏まえて展開すると下記のようになります。

__SC_LONG() マクロの展開結果の例


__SC_LONG(int, magic1),

↓ __TYPE_IS_LL() を展開

__typeof(
  __builtin_choose_expr(
    (__same_type((int)0, 0LL) ||
     __same_type((int)0, 0ULL)), 0LL, 0L))
      magic1,

↓ __same_typeを展開

__typeof(
  __builtin_choose_expr(
    (__builtin_types_compatible_p(typeof((int)0), typeof(0LL)) ||
     __builtin_types_compatible_p(typeof((int)0), typeof(0ULL))), 0LL, 0L))
       magic1,

最内側の__same_type() は引数に渡した値の型を比較するマクロです。マクロで使用する __builtin_types_compatible_p() は1つ目と2つ目の型が同じかどうか？をintで返す組み込み関数、typeof() は引数の型を返すキーワードです（関数ではないので値は返しません）。

その他の組み込み関数のマニュアル（__builtin_types_compatible_p() も載っている）
typeofのマニュアル

従って__same_type((int)0, 0LL) はintと0LLの型、int型とlong long int型が等しいか比較しています。当然、等しくありません。ちなみにintは __SC_LONG(int, magic1) の最初の引数intから来たことを思い出していただけると嬉しいです。例えば __SC_LONG(long long, magic1) であれば比較結果は等しいと判断されるでしょう。

最内側の条件式 __same_type((int)0, 0LL) || __same_type((int)0, 0ULL)) の部分は型がlong longもしくはunsigned long longかどうか？を調べています。

判断結果を受け取る__builtin_choose_expr(const_exp, exp1, exp2) は、const_expが真なら、exp1を返し、偽ならexp2を返す組み込み関数です。もしconst_expがコンパイル時に判定できなければ、コンパイルエラーです。

以上をまとめると __SC_LONG(AAA, BBB) は、

AAAがlong longもしくはunsigned long longならlong long BBB
AAAがそれ以外の型ならばlong BBB

という働きをします。また __SC_CAST() はその名の通りキャストを生成します。

__SC_CAST() マクロの実装


// linux/include/linux/syscalls.h

#define __SC_CAST(t, a)	(__force t) a

です。長いですね。続きはまた今度。

編集者:すずき(2023/02/04 00:56)

コメント一覧

コメントはありません。

この記事にコメントする

2023年2月3日

permalink

編集する

RISC-V 64bit Linuxとシステムコールと32bitの引数その3 - SYSCALL_DEFINEマクロ

目次: RISC-V

昨日の続きです。「64bit環境においてシステムコールの引数がレジスタ長（= 64bit）以下だった場合（例えばintが典型例）、どう扱うか？」コードの解説編です。

どうして符号拡張されるのか？逆アセンブルで説明したつもりになってはいけない、逃げてはダメだ！という熱心なあなたのために、マクロを展開しながら説明します。今回の解説はSYSCALL_DEFINE4() たった1行です。

rebootシステムコールの実装


// linux/kernel/reboot.c

SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
		void __user *, arg)
{

...


// linux/include/linux/syscalls.h

#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)

#define SYSCALL_DEFINEx(x, sname, ...)				\
	SYSCALL_METADATA(sname, x, __VA_ARGS__)			\
	__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

下記のように展開されます。

SYSCALL_DEFINE4() の展開結果


SYSCALL_METADATA(_reboot, 4, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)
__SYSCALL_DEFINEx(4, _reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)

SYSCALL_METADATA() の方は関数の実体と無関係なので今回は無視して、__SYSCALL_DEFINEx() を見ます。

__SYSCALL_DEFINEx() マクロの実装


// linux/include/linux/syscalls.h

/*
 * The asmlinkage stub is aliased to a function named __se_sys_*() which
 * sign-extends 32-bit ints to longs whenever needed. The actual work is
 * done within __do_sys_*().
 */
#ifndef __SYSCALL_DEFINEx
#define __SYSCALL_DEFINEx(x, name, ...)					\
	__diag_push();							\
	__diag_ignore(GCC, 8, "-Wattribute-alias",			\
		      "Type aliasing is used to sanitize syscall arguments");\
	asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))	\
		__attribute__((alias(__stringify(__se_sys##name))));	\
	ALLOW_ERROR_INJECTION(sys##name, ERRNO);			\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
	asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));	\
	asmlinkage long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))	\
	{								\
		long ret = __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));\
		__MAP(x,__SC_TEST,__VA_ARGS__);				\
		__PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));	\
		return ret;						\
	}								\
	__diag_pop();							\
	static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
#endif /* __SYSCALL_DEFINEx */

長いマクロですね。rebootシステムコールの宣言部分 __SYSCALL_DEFINE4(reboot, ...) は下記のように展開されます。

SYSCALL_DEFINE4() の展開結果


SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
		void __user *, arg)

↓

__diag_push();

__diag_ignore(GCC, 8, "-Wattribute-alias", "Type aliasing is used to sanitize syscall arguments");

asmlinkage long sys_reboot(__MAP(4,__SC_DECL,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)) __attribute__((alias(__stringify(__se_sys_reboot))));

ALLOW_ERROR_INJECTION(sys_reboot, ERRNO);

static inline long __do_sys_reboot(__MAP(4,__SC_DECL,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));

asmlinkage long __se_sys_reboot(__MAP(4,__SC_LONG,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));

asmlinkage long __se_sys_reboot(__MAP(4,__SC_LONG,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg))
{
	long ret = __do_sys_reboot(__MAP(4,__SC_CAST,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));
	__MAP(4,__SC_TEST,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg);
	__PROTECT(4, ret,__MAP(4,__SC_ARGS,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));
	return ret;
}

__diag_pop();

static inline long __do_sys_reboot(__MAP(4,__SC_DECL,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));

色々興味深い部分（__diag_push, __diag_ignore, などなど）はありますが、関数と関係ないので無視して、符号拡張を行う __se_sys_reboot() の実装部分を見ます。

SYSCALL_DEFINE4() の関数実装部分の抜粋


asmlinkage long __se_sys_reboot(__MAP(4,__SC_LONG,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg))
{
	long ret = __do_sys_reboot(__MAP(4,__SC_CAST,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));
	__MAP(4,__SC_TEST,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg);
	__PROTECT(4, ret,__MAP(4,__SC_ARGS,int, magic1, int, magic2, unsigned int, cmd, void __user *, arg));
	return ret;
}

この関数本体の部分がどう展開されるかを見ます。続きはまた今度。

編集者:すずき(2023/02/03 09:57)

コメント一覧

コメントはありません。

この記事にコメントする

2023年2月2日

permalink

編集する

RISC-V 64bit Linuxとシステムコールと32bitの引数その2 - Linuxの動作

目次: RISC-V

昨日の続きです。64bit Linux環境のreboot() はmagicの符号拡張をしてもしなくても正常に動くという話をしました。

この話はrebootには限らないので、もっと一般化すると「64bit環境においてシステムコールの引数がレジスタ長（= 64bit）以下だった場合（例えばintが典型例）、どう扱うか？」となります。

動作を確認するにはデバッガで追えば早いでしょう。RISC-V 64bit向けに、

musl libcを使うツールチェーン（後述）
GNU libcを使うツールチェーン（後述）
linux
busybox
QEMU

を用意して起動します。符号拡張を行わないmusl libc版のツールチェーンでbusyboxをビルドしてQEMU起動、GDBでアタッチします。

QEMUの起動、GDBからのアタッチ

$ qemu-system-riscv64 \
  -machine virt \
  -net none \
  -nographic \
  -chardev stdio,id=con,mux=on \
  -serial chardev:con -mon chardev=con,mode=readline \
  -kernel linux/arch/riscv/boot/Image \
  -initrd busybox/initramfs.cpio \
  -s


$ riscv64-unknown-linux-gnu-gdb linux/vmlinux

(gdb) target remote :1234

...

Linuxのシステムコールの実装は下記のようになります。SYSCALL_DEFINE() とはなんぞや？というところが気になると思いますが、今はひとまずシステムコール名の頭に __do_sys_ を付けた関数が定義されると理解しておけば大丈夫です。

Linuxのrebootシステムコールの実装



//linux/kernel/reboot.c

SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
		void __user *, arg)
{

...

ブレークポイントを __do_sys_rebootに仕掛けてQEMU側のコンソールでbusybox poweroffコマンドを実行します。

__do_sys_reboot() のmagic1引数の値（符号拡張されている）

(gdb) b __do_sys_reboot
Breakpoint 1 at 0xffffffff8002d860: file kernel/reboot.c, line 702.

(gdb) c
Continuing.

Breakpoint 1, __do_sys_reboot (magic1=-18751827, magic2=672274793,
    cmd=1126301404, arg=0x4321fedc) at kernel/reboot.c:702
702     {

(gdb) p/x $a0
$1 = 0xfffffffffee1dead

システムコールの引数は負の数（つまり0xffffffff_fee1dead）となっています。この関数に辿り着く前に符号拡張されるようです。

バックトレース表示

(gdb) bt
#0  __do_sys_reboot (magic1=-18751827, magic2=672274793, cmd=1126301404,
    arg=0x4321fedc) at kernel/reboot.c:702
#1  0xffffffff8002dab2 in __se_sys_reboot (magic1=<optimized out>,
    magic2=<optimized out>, cmd=<optimized out>, arg=<optimized out>)
    at kernel/reboot.c:700
#2  0xffffffff80002fe2 in handle_exception () at arch/riscv/kernel/entry.S:231
Backtrace stopped: frame did not save the PC

バックトレースを見ると__se_sys_reboot() という関数も呼ばれています。この関数を調べるためにブレークを掛けて再度実行します。

__se_sys_reboot() のmagic1引数の値（符号拡張なし）

(gdb) b __se_sys_reboot
Breakpoint 1 at 0xffffffff8002daa0: file kernel/reboot.c, line 700.

(gdb) c
Continuing.

Breakpoint 1, __se_sys_reboot (magic1=4276215469, magic2=672274793,
    cmd=1126301404, arg=1126301404) at kernel/reboot.c:700
700     SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,

(gdb) p/x $a0
$1 = 0xfee1dead

システムコール例外ハンドラに渡ってきた引数magicはレジスタa0に入っていて、値は0xfee1deadです。__do_sys_reboot() や __se_sys_reboot() 関数を定義するSYSCALL_DEFINE() はマクロのため、デバッガから見てもソースコードが表示されません。

不思議なSYSCALL_DEFINE() マクロの仕組みは後日調べるとして、とりあえず今は逆アセンブルします。

__se_sys_reboot() の逆アセンブル

(gdb) disas
Dump of assembler code for function __se_sys_reboot:
=> 0xffffffff8002daa0 <+0>:     addi    sp,sp,-16
   0xffffffff8002daa2 <+2>:     sd      s0,0(sp)
   0xffffffff8002daa4 <+4>:     sd      ra,8(sp)
   0xffffffff8002daa6 <+6>:     addi    s0,sp,16
   0xffffffff8002daa8 <+8>:     sext.w  a2,a2    ★
   0xffffffff8002daaa <+10>:    sext.w  a1,a1    ★
   0xffffffff8002daac <+12>:    sext.w  a0,a0    ★
   0xffffffff8002daae <+14>:    jal     ra,0xffffffff8002d860 <__do_sys_reboot>
   0xffffffff8002dab2 <+18>:    ld      ra,8(sp)
   0xffffffff8002dab4 <+20>:    ld      s0,0(sp)
   0xffffffff8002dab6 <+22>:    addi    sp,sp,16
   0xffffffff8002dab8 <+24>:    ret

RISC-Vのアセンブラを見たことない方のために補足すると、sext.wという命令はRISC-Vの符号拡張命令です。また引数はa0, a1, a2, a3, a4, a5レジスタを経由して渡されます。すなわち __se_sys_reboot() 関数はa0, a1, a2レジスタ（引数magic1, magic2, cmdに相当）を符号拡張して __do_sys_reboot() 関数に渡しています。

ここで当初の疑問が解消しますね。疑問の内容は下記の通りで、

magic1に0xffffffff_fee1deadを渡す派（GNU libc）→ 符号拡張するが値は変わらず
magic1に0x00000000_fee1deadを渡す派（musl libc）→ 符号拡張して0xffffffff_fee1deadにする

答えは途中で符号拡張しているのでどちらでも問題なかった、というわけです。なるほどね。

補足: ツールチェーンの準備

ツールチェーンのビルドはcrosstool-NGなどでもできますし、面倒な場合はGitHubにUbuntu 20.04用の *.debファイルを置いたのでお使いください。

GNU libcの場合は、

またmusl libcの場合は、

をお使いください。

編集者:すずき(2023/02/02 21:07)

コメント一覧

コメントはありません。

この記事にコメントする

2023年2月1日

permalink

編集する

RISC-V 64bit Linuxとシステムコールと32bitの引数その1 - libcの実装

目次: RISC-V

タイトルに反して実はRISC-Vはあまり関係ないですが……。GNU libcとmusl libcの実装を見ていたら、64bit環境でrebootシステムコールの引数magicに、

0x00000000_fee1deadを渡す派（musl libc）
0xffffffff_fee1deadを渡す派（GNU libc）

がいることに気づきました。

musl libcとGNU libcの実装

Cライブラリのrebootの関数宣言はint reboot(int cmd) となっています。musl libcの場合0xfee1deadをキャストせずlong型の引数に渡します。符号拡張は行われず0x00000000_fee1deadがシステムコールの引数に渡されます。

musl libcのreboot() の実装


// musl/src/linux/reboot.c

int reboot(int type)
{
	return syscall(SYS_reboot, 0xfee1dead, 672274793, type);
}


// musl/arch/riscv64/syscall_arch.h

static inline long __syscall3(long n, long a, long b, long c)
{
	register long a7 __asm__("a7") = n;
	register long a0 __asm__("a0") = a;
	register long a1 __asm__("a1") = b;
	register long a2 __asm__("a2") = c;
	__asm_syscall("r"(a7), "0"(a0), "r"(a1), "r"(a2))
}

一方のGNU libcの場合は、0xfee1deadをintにキャストしてからシステムコールに渡します。この値は負の数なので符号拡張が行われて0xffffffff_fee1deadがシステムコールの引数に渡されます。

GNU libcのreboot() の実装


// glibc/sysdeps/unix/sysv/linux/reboot.c

/* Call kernel with additional two arguments the syscall requires.  */
int
reboot (int howto)
{
  return INLINE_SYSCALL (reboot, 3, (int) 0xfee1dead, 672274793, howto);
}


// glibc/sysdeps/unix/sysv/linux/riscv/sysdep.h

# define internal_syscall3(number, arg0, arg1, arg2)      		\
({ 									\
	long int _sys_result;						\
	long int _arg0 = (long int) (arg0);				\
	long int _arg1 = (long int) (arg1);				\
	long int _arg2 = (long int) (arg2);				\
									\
	{								\
	register long int __a7 asm ("a7") = number;			\
	register long int __a0 asm ("a0") = _arg0;			\
	register long int __a1 asm ("a1") = _arg1;			\
	register long int __a2 asm ("a2") = _arg2;			\
	__asm__ volatile ( 						\
	"scall\n\t" 							\
	: "+r" (__a0)							\
	: "r" (__a7), "r" (__a1), "r" (__a2)				\
	: __SYSCALL_CLOBBERS); 						\
	_sys_result = __a0;						\
	}								\
	_sys_result;							\
})

最初に気づいたときはどちらかがバグっている……？と勘違いしましたが、当たり前ですがどちらも正常に動きます。すなわちLinux側で何か対応しているはずです。続きはまた今度。

編集者:すずき(2023/02/20 23:39)

コメント一覧

コメントはありません。

この記事にコメントする

2023年1月27日

permalink

編集する

LXDE + GTKで日本語と英語を混ぜるとズレる（続き）

目次: Linux

昨日（2023年1月26日の日記参照）の続きです。タイトルに「日本語 → 英語」の順の文字列を表示させると英語がズレてしまう問題についてです。

ルック＆フィールの設定からフォントを変えて試したところ、源ノ角ゴシックの一部の太さ（Normalのみ）でこの問題が発生することが分かりました。実際に見てもらった方が分かりやすいと思います。

源ノ角ゴシックJP Normal（英語が上にズレる）

源ノ角ゴシックJP Regular（英語がズレない）

原因が良くわからないままですが、とりあえず源ノ角ゴシックを使うならNormal以外の太さを選択することで英語が上にズレてしまう問題を回避できそうです。

NormalだろうがRegularだろうが同じフォントだと思っていたんですけど、何か違うんでしょうか？？フォントのレンダリングは良くわからないね……。

編集者:すずき(2024/01/13 14:30)

コメント一覧

コメントはありません。

この記事にコメントする

2023年1月26日

permalink

編集する

LXDE + GTKで日本語と英語を混ぜるとズレる

目次: Linux

タイトルのままなのですが、普段使いしているLinux環境（Debian Testing, LXDE）にて英語の位置がたまにズレていることがあります。どういうときにズレるのか気になったので、いくつかパターンを試しました。残念ながら原因や直し方までは調べていないので良くわかりません。

結論を先に書いておくと、日本語のあとに英語を書くとズレます。英語のあとに日本語を書いてもズレません。不思議ですね。

タイトルに日本語のみ表示

タイトルに英語、日本語の順で表示

タイトルに英語、日本語、英語の順で表示

タイトルに日本語、英語の順で表示（英語が上にズレる）

この画像をキャプチャしているときに気が付いたのですが、Leafpadのテキストボックスでも同じ現象が発生していました。

Leafpadのテキストボックスも同様の現象

何なんでしょうね？GTK+ の仕様なんでしょうか？

編集者:すずき(2024/01/13 14:31)

コメント一覧

コメントはありません。

この記事にコメントする

2023年1月24日

permalink

編集する

老舗VODサービスの開始時期

NetFlixのような老舗に属するVODサービスって一時期に一気に増えたよね？という印象を持っていたのですが、調べたことがなかったので調べがてらメモしておきます。

ベンダー	創業国	創業国サービスイン	日本サービスイン
Amazon	アメリカ	2006	2015/09
Hulu	アメリカ	2007	2011/09
NetFlix	アメリカ	2007	2015/09
U-NEXT	日本	2007	同左

注意点としては創業 = サブスクリプション開始、ではないことです。今やVODサービスといえば定額制度（サブスクリプション制度、サブスク）が当たり前ですが、以前は1つの動画に1度支払う制度（PPV: Pay-Per-View制度）が普通でした。

したがって老舗VOD企業達も創業時にサブスクリプション制度を展開していたとは限りません。例えばHuluはPPVで参入、サブスク（Hulu Plus）の開始は2010年です。

といった細かい話をあえて無視すれば「老舗VOD企業は2007年に出揃った」と言ってしまって良いでしょう。

編集者:すずき(2023/01/26 21:11)

コメント一覧

コメントはありません。

この記事にコメントする

2023年1月22日

permalink

編集する

電気代が高いよ

リモートワークが当たり前になり家に居る時間が長くなりました。当然、家に居れば電気を使いますので電気代も上がります。2021年はそれで説明が付いたんですけど、去年2022年の電気代はライフスタイルの変化では説明できないほど明らかに高いです。何が起きたの……？？

まずは今までの電気使用量をおさらいします。あ、ちなみに契約している電力会社はSymEnergy（公式サイトへのリンク）という会社です。

過去4年間の電気使用量

電気代を使用量で割ってkWh平均、いわゆる単価相当の数値を出します。厳密にいうと電気代は複数段階料金制のため、電気代を使用量で割っても単価は出せないのですが、飛びぬけて使用量が少なかったり多かったりした月はないので、細かいことは気にしなくて良いです。

過去4年間のkWhあたりの電気代

予想はしていましたがkWh単価が1.5倍（2021/12: 28.00円/kWh, 2022/12: 40.96円/kWh）です。そりゃ高い訳だ……ヒエー勘弁してくれえ。

もったいない原子力発電所

電気関係の話題でもう一つ。福島第一原子力発電所の事故は日本国民に原発アレルギーを引き起こしたようで、原子力発電所を動かすor動かさないであらゆる地域がもめています。ちなみに今の稼働率はどの程度でしょうか？

データは原子力規制委員会が公開していて（原子力発電所の現在の運転状況 - 原子力規制委員会）簡単に見ることができます。各発電所の出力も公開されていますが、ちょっとサボってWikipediaから数値を持ってきました。間違っていたらごめんなさい。

各電力会社ごとに運転状況をグラフにしました。灰色が廃炉（または廃炉検討中）、オレンジが停止中、青が運転中です。

日本の原子力発電所の稼働割合

見てのとおり関西、四国、九州以外は全く運転していません。定格出力をグラフにすると、保有量が多いのは東京（柏崎刈羽）、関西（美浜、大飯、高浜）ですが、ほとんど活かされていないことがわかります。

日本の原子力発電所の稼働＆出力

東京電力なんかは柏崎刈羽原発だけで821万kWも出力があって、東電管内の太陽光発電の「ピーク値」である1200万kWの7割を充足する発電量です。強いですね。

原子力発電所を新たに建てるか建てないは人によって思うところがあるでしょうけど、既に建ててあるのに使わず風化させるのは勿体ないなあと思います……。

編集者:すずき(2023/01/26 21:50)

コメント一覧

コメントはありません。

この記事にコメントする

もっと前

2023年2月4日 >>> 2023年1月22日

もっと後

管理用メニュー

記事を新規作成

RSSを更新

<	2023					>
<<	<	02			>	>>
日	月	火	水	木	金	土
-	-	-	1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	-	-	-	-

本日の日記へ

最近のコメント5件

24年10月1日
すずきさん (10/06 03:41)
「xrdpで十分動作しているので、Wayl...」
24年10月1日
hdkさん (10/03 19:05)
「GNOMEをお使いでしたら今はWayla...」
24年10月1日
すずきさん (10/03 10:12)
「私は逆にVNCサーバーに繋ぐ使い方をした...」
24年10月1日
hdkさん (10/03 08:30)
「おー、面白いですね。xrdpはすでに立ち...」
14年6月13日
2048player...さん (09/26 01:04)
「最後に、この式を出すのに紙4枚(A4)も...」

もっとみる

こんてんつ

wiki

pukiwiki

Linux JM

Java API

Java 8

Java 7

Java 6

Java 2 SE 5.0
link

Java 2 SE 1.4.0
link

Java 2 SE 1.3
link

Java Media Framework 2.0

過去の日記

2002年

8月 9月
10月 11月 12月

2003年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2004年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2005年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2006年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2007年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2008年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2009年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2010年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2011年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2012年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2013年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2014年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2015年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2016年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2017年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2018年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2019年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2020年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2021年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2022年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2023年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月 12月

2024年

1月 2月 3月
4月 5月 6月
7月 8月 9月
10月 11月

過去日記について

生成ログ

その他の情報

アクセス統計

エージェントごと

ホストごと

履歴

サーバ一覧

マスタ(SAKURA)
link

ミラー(自宅)

サイトの情報

HTML 4.01 Strict
check passed

CSS3

合計: counter total
本日: counter today

link About www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 11/04 15:17

管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)

This is Simple Diary 1.0 Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.2.24. using GD 2.3.3(png support.)

RISC-V 64bit Linuxとシステムコールと32bitの引数 その4 - __MAP(), __SC_X() マクロの実装

任意の引数に変換を掛ける __MAP() マクロ

__MAP() マクロの実装

__MAP() マクロの展開結果の例

キャストの要、__SC_LONG(), __SC_CAST() マクロ

__SC_LONG() マクロの実装

__SC_LONG() マクロの展開結果の例

__SC_CAST() マクロの実装

コメント一覧

RISC-V 64bit Linuxとシステムコールと32bitの引数 その3 - SYSCALL_DEFINEマクロ

rebootシステムコールの実装

SYSCALL_DEFINE4() の展開結果

__SYSCALL_DEFINEx() マクロの実装

SYSCALL_DEFINE4() の展開結果

SYSCALL_DEFINE4() の関数実装部分の抜粋

コメント一覧

RISC-V 64bit Linuxとシステムコールと32bitの引数 その2 - Linuxの動作

QEMUの起動、GDBからのアタッチ

Linuxのrebootシステムコールの実装

__do_sys_reboot() のmagic1引数の値（符号拡張されている）

バックトレース表示

__se_sys_reboot() のmagic1引数の値（符号拡張なし）

__se_sys_reboot() の逆アセンブル

補足: ツールチェーンの準備

コメント一覧

RISC-V 64bit Linuxとシステムコールと32bitの引数 その1 - libcの実装

musl libcとGNU libcの実装

musl libcのreboot() の実装

GNU libcのreboot() の実装

コメント一覧

LXDE + GTKで日本語と英語を混ぜるとズレる（続き）

コメント一覧

LXDE + GTKで日本語と英語を混ぜるとズレる

コメント一覧

老舗VODサービスの開始時期

コメント一覧

電気代が高いよ

もったいない原子力発電所

コメント一覧

管理用メニュー

こんてんつ

過去の日記

その他の情報

RISC-V 64bit Linuxとシステムコールと32bitの引数その4 - MAP(), SC_X() マクロの実装

RISC-V 64bit Linuxとシステムコールと32bitの引数その3 - SYSCALL_DEFINEマクロ

RISC-V 64bit Linuxとシステムコールと32bitの引数その2 - Linuxの動作

RISC-V 64bit Linuxとシステムコールと32bitの引数その1 - libcの実装