UNIX Network Management Guide (Moe Moe Unix!)

OTA Takashi

未読、

2003/05/06 12:36:372003/05/06

To:

おおたです。
fj.net.misc は削って fj.unix をくわえます．Followup-To: fj.unix

shibuyaさんが2003年05月03日(土) 20時00分44秒に、
fj.net.misc,fj.booksに投稿した<3EB3A15C...@dd.iij4u.or.jp>の記事から

> page[100110010](306) su [正]: su - substitute user identity [誤]: super userの略

これはOSによって諸説あるんじゃありませんでしたっけ．
大昔に UNIX USER 誌でネタにされていたような．
そのときは，switch user と substitute user と super user がある，
という話でしたが．

(SunOS 5.6, 5.8)
NAME
su - become super user or another user

(LASER5 Linux 6.2 と Red Hat Linux 7.1)
NAME
su - run a shell with substitute user and group IDs

(IRIX 6.5)
NAME
su - become superuser or another user

うーん，SunOS 4.1.4 はしばらく前まで使えたんですが，今はない……．

----------- ニュースはみんなのために／｜＼メールは個人のために -----------
太田尚志 - OTA Takashi - http://web.sfc.keio.ac.jp/~t00156to/ ICQ#:39782589

IIJIMA Hiromitsu

未読、

2003/05/06 19:34:462003/05/06

To:

いいじまです。

> > page[100110010](306) su [正]: su - substitute user identity [誤]: super userの略
>
> これはOSによって諸説あるんじゃありませんでしたっけ．
> 大昔に UNIX USER 誌でネタにされていたような．
> そのときは，switch user と substitute user と super user がある，
> という話でしたが．
>
> (SunOS 5.6, 5.8)
> NAME
> su - become super user or another user
>
> (LASER5 Linux 6.2 と Red Hat Linux 7.1)
> NAME
> su - run a shell with substitute user and group IDs
>
> (IRIX 6.5)
> NAME
> su - become superuser or another user
>
> うーん，SunOS 4.1.4 はしばらく前まで使えたんですが，今はない……．

http://www.freebsd.org/cgi/man.cgi で調べた限りでは

FreeBSD 4.7-RELEASE、2.10 BSD、NetBSD 1.6.1、OpenBSD 3.2
|NAME

| su - substitute user identity

HPUX 11.22
|NAME
| su - switch user

Minix 2.0
|NAME
| su - temporarily log in as superuser or another user

OSF1 V5.1/alpha、UNIX 7th Ed.
|NAME
| su - Substitutes user ID temporarily

SunOS 4.1.3
|NAME
| su - super-user, temporarily switch to a new user ID

Ultrix 4.2
|Name
| su - substitute a user ID

deutsch-Linux/GNU
|BEZEICHNUNG
| su - (superuser) ändert User und Gruppen ID

ですね。

AT&T UNIX ver.1 のころからあるコマンドだそうですので、そういう古いものを
あたってみると真相が分かるかもしれません。

========================================================================
飯嶋浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp

───【今日のひとこと】────────────────────────
大きな嘘はついてもいいが、小さな嘘をついてはいけない。
　　　　　　　　　　　──岡田斗司夫（東京大学「オタク文化論ゼミ」より）
　　　　──こだま兼嗣（映画「名探偵コナン　瞳の中の暗殺者」パンフより）
────────────────────────────────────

mihi~star

未読、

2003/05/06 20:01:442003/05/06

To:

こんにちは、飯嶋浩光さん。みひ～☆です。

>>>>> IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> さんの wrote:
>>>>> in <3EB84696...@ht.sakura.ne.jp> より

>
> > > page[100110010](306) su [正]: su - substitute user identity [誤]: super userの略
> >
> > これはOSによって諸説あるんじゃありませんでしたっけ．
> > 大昔に UNIX USER 誌でネタにされていたような．
> > そのときは，switch user と substitute user と super user がある，
> > という話でしたが．
>

> AT&T UNIX ver.1 のころからあるコマンドだそうですので、そういう古いものを
> あたってみると真相が分かるかもしれません。

http://minnie.tuhs.org/UnixTree/V7/usr/man/man1/su.1.html を
見ると、
: su - substitute user id temporarily
となっています。

一方、
http://minnie.tuhs.org/UnixTree/V5/usr/source/s2/su.c.html や
http://minnie.tuhs.org/UnixTree/V6/usr/source/s2/su.c.html の
コメント部分を見ると、
: /* su -- become super-user */
となっています。V7以前のman1には、suに関する記述はありません。

＃http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/su.c.html には、
　コメント部分が見あたりません。

というわけで、当初の作者には、super userになるためのものという
意識があったのでしょう。

それでは。
--
mihi~star <mi...@childstar.club.ne.jp>
あと少し探せばきっと見つかりますよっ♪

Nagata

未読、

2003/05/06 22:49:162003/05/06

To:

☆Subject: Re: UNIX Network Management Guide (Moe Moe Unix!)

In article <b98oal$f77$1...@news.sfc.keio.ac.jp>
t00156...@sfc.keio.ac.jp writes:

>> うーん，SunOS 4.1.4 はしばらく前まで使えたんですが，今はない……．

/usr/etc/os_release
> SunOS Release 4.1.4-JLE1.1.4
> OS/AS Version 4.14 R0

man su

> su - 新しいユーザIDへの一時的な切り替え（スーパーユーザ）

unsetenv LANG
man su

> su - super-user, temporarily switch to a new user ID

--
yna...@st.rim.or.jp
わぁい、みひーさんだ。
自宅では、2038年まで某プロバイダからもらった某 JLE を使う予定(笑)

KATAYAMA Yoshio

未読、

2003/05/06 23:28:292003/05/06

To:

片山＠ＰＦＵです。

In article <87u1c7i...@artemis.scn-net.ne.jp>,
mihi~star <mi...@childstar.club.ne.jp> writes:

>一方、
>http://minnie.tuhs.org/UnixTree/V5/usr/source/s2/su.c.html や
>http://minnie.tuhs.org/UnixTree/V6/usr/source/s2/su.c.html の
>コメント部分を見ると、
>: /* su -- become super-user */
>となっています。V7以前のman1には、suに関する記述はありません。

man8 にありませんか。手元の 6th Edition のマニュアルは 8章が欠落
していますが、目次では、

VIII. SYSTEM MAINTENANCE
（省略）
su ・・・・・・・・ become privileged user

となっています。
--
片山＠ＰＦＵ

mihi~star

未読、

2003/05/07 7:19:112003/05/07

To:

こんにちは、片山善夫さん。みひ～☆です。

>>>>> KATAYAMA Yoshio <ka...@pfu.fujitsu.com> さんの wrote:
>>>>> in <KATE.03M...@flash.tokyo.pfu.co.jp> より

>
> >http://minnie.tuhs.org/UnixTree/V6/usr/source/s2/su.c.html の
> >コメント部分を見ると、
> >: /* su -- become super-user */
> >となっています。V7以前のman1には、suに関する記述はありません。
>
> man8 にありませんか。手元の 6th Edition のマニュアルは 8章が欠落
> していますが、目次では、
> VIII. SYSTEM MAINTENANCE
> （省略）
> su ・・・・・・・・ become privileged user
> となっています。

ひゃー、ほんとだ。^^; ちゃんと検索エンジンを見ておけばよかった。
おっしゃるとおり、man8にありました。
http://minnie.tuhs.org/UnixTree/V3/usr/man/man8/su.8.html
http://minnie.tuhs.org/UnixTree/V4/usr/man/man8/su.8.html
http://minnie.tuhs.org/UnixTree/V6/usr/man/man8/su.8.html
です。
V3のものを見ると、 'SU (VIII)'1/20/73'SU (VIII)' だって。
Unixも而立の歳ですね。

それでは。
＃2038年まで使える(?)IA-64マシンが欲しいです。
　落ちてたら教えてください。(もちろん落ちてない)

MOCHIDA Shuji

未読、

2003/05/07 21:21:092003/05/07

To:

持田＠NETside です。

> ＃2038年まで使える(?)IA-64マシンが欲しいです。

time_t が 64bit でちゃんと動く OS が載ってれば、32bit アーキテクチャでも
2038 年以降も大丈夫だと思いますよ。逆に 64bit アーキの 64bit OS だからと
言って、2038 年以降大丈夫かというと必ずしもそうとは限らないと思います。
＃ LP64 で int にキャストして代入してたりしたら一緒ですから。

> 　落ちてたら教えてください。(もちろん落ちてない)

Alpha や UltraSPARC だと割と落ちてませんか?(笑)

そうじゃなくて、64bit な OS 上で Unix V3 の su.c をコンパイルして、
2038 年以降まで使いたい、って話かな? ＃んなわきゃないか。(笑)

--
持田修司 NETside Technologies Inc.
-- Equal Opportunity for All Good Architectures, NetBSD. --

KATAYAMA Yoshio

未読、

2003/05/07 23:42:292003/05/07

To:

In article <ul8y91i...@pine.yorie.netside.co.jp>,
MOCHIDA Shuji <moc...@netside.co.jp> writes:

>> ＃2038年まで使える(?)IA-64マシンが欲しいです。
>> 　落ちてたら教えてください。(もちろん落ちてない)

> Alpha や UltraSPARC だと割と落ちてませんか?(笑)

あと 35 年も壊れずに動き続けられるとは思えないんですが、、、:-p
--
片山＠ＰＦＵ

Nagata

未読、

2003/05/08 5:53:182003/05/08

To:

fj.comp.misc かなぁ、と思いつつ続かないと信じてこのまま(汗)
＃ fj.comp.64bit とか fj.sys.64bit とかあるといいかも :-p

☆Subject: Re: UNIX Network Management Guide (Moe Moe Unix!)

In article <87issnh...@artemis.scn-net.ne.jp>
mi...@childstar.club.ne.jp writes:

>> ＃2038年まで使える(?)IA-64マシンが欲しいです。
>> 　落ちてたら教えてください。(もちろん落ちてない)

IA-64 って mips だっけ(汗)、な私がフォローしてはいけない
気がしますが、ちょっと検索すると SGI の 750 は製造してない
みたいでサーバは超高額。 IBM 位でしょうか。

IntelliStation Z Pro とか検索すると 120万が 40万円位で
あるみたいです。中古かも。
＃といっても個人では買えない値段 :-p

--
yna...@st.rim.or.jp
ってそれくらい、みひーさんならご存知ですよね m(..)m

昔は最新機種を追いかけた職場でしたが、最近は、最古な環境で
最新のチップの…(ごほごほ)

Nobuhiro Shibuya at Office

未読、

2003/05/08 7:52:362003/05/08

To:

渋谷@職場からです

Nagata wrote:

> IA-64 って mips だっけ(汗)、な私がフォローしては

IntelとHewlett Packard (Compaqとの合併前) の共同開発では？
--
mailto:shi...@dd.iij4u.or.jp
Nobuhiro Shibuya at Office
Tokyo Japan

IIJIMA Hiromitsu

未読、

2003/05/08 8:03:562003/05/08

To:

いいじまです。

> IA-64 って mips だっけ(汗)、な私がフォローしてはいけない
> 気がしますが、

IA ってのは Intel architecture のことで、要するに IA-64 とは Itanium の
ことです。

他には Alpha や最近の SPARC が 64 ビットプロセッサですね。

Nobuhiro Shibuya at Office

未読、

2003/05/08 8:22:212003/05/08

To:

IIJIMA Hiromitsu wrote:

> いいじまです。

> 他には Alpha や最近の SPARC が 64 ビットプロセッサですね。

最後の頃のPA-RISC(HP)も。
それとも　IA-64って PA-RISC のスーパーセットでしたっけ？

IIJIMA Hiromitsu

未読、

2003/05/08 9:27:462003/05/08

To:

いいじまです。

> それとも　IA-64って PA-RISC のスーパーセットでしたっけ？

命令的には IA-32（＝x86）の名残が色々あるような。
整数レジスタが R0～R15 の 16 本あるのですが、R0～R7 には RAX, RBX, RCX,
RDX, RSI, RDI, RBP, RSP（順不同）という別名がついていたはずです。

Nobuhiro Shibuya

未読、

2003/05/08 10:04:472003/05/08

To:

渋谷@家からです。

みょうな方向に話題が進んでいますが…

MOCHIDA Shuji wrote:

> 持田＠NETside です。
>
> > ＃2038年まで使える(?)IA-64マシンが欲しいです。
>
> time_t が 64bit でちゃんと動く OS が載ってれば、32bit アーキテクチャでも
> 2038 年以降も大丈夫だと思いますよ。逆に 64bit アーキの 64bit OS だからと
> 言って、2038 年以降大丈夫かというと必ずしもそうとは限らないと思います。

という突っ込みが既に入っているように

] 2038-01-19 03:14:07 UTC

の前後に「その時歴史は動いた」の瞬間がやってくるはずですよね。
# 閏秒問題のため数秒の誤差があります。
--
mailto:shi...@dd.iij4u.or.jp
Nobuhiro Shibuya, Tokyo Japan

MOCHIDA Shuji

未読、

2003/05/08 10:11:222003/05/08

To:

持田＠NETside です。

> 他には Alpha や最近の SPARC が 64 ビットプロセッサですね。

最近? UltraSPARC は PentiumPro と同時期くらいじゃなかったですか?
もうちょっと古いかな?
＃もっとも、いっちゃん最初のやつはバグってて 64bit ペケだったような。

もちろん Alpha はそれよりずっと前。

＃「最近の SH は」とかならわかる。

ARM ぐらいじゃないですか? 64bit 化聞かないの。

MOCHIDA Shuji

未読、

2003/05/08 10:23:332003/05/08

To:

持田＠NETside です。

> あと 35 年も壊れずに動き続けられるとは思えないんですが、、、:-p

それは言える... 電解コンデンサー交換する必要がありますね..
ファンはあるだろうけど、電源ユニットもなんとかするとして、
SCA の HDD はもう無さそう。Ethernet はまだあるかな..

今から 35 年前つうと 1968 年製、まだ動いてるんでしょうか..
＃ 2.11BSD とかで。

Kusakabe Youichi

未読、

2003/05/08 12:44:482003/05/08

To:

In article <b98oal$f77$1...@news.sfc.keio.ac.jp>, OTA Takashi

<t00156...@sfc.keio.ac.jp> wrote:
> > page[100110010](306) su [正]: su - substitute user identity [誤]:
> > super userの略
>
> これはOSによって諸説あるんじゃありませんでしたっけ．
> 大昔に UNIX USER 誌でネタにされていたような．
> そのときは，switch user と substitute user と super user がある，
> という話でしたが．

suspend userだと思ってました ;)

--
ヘ_ヘ ____________________________
ミ・・ミ vo...@merope.pleiades.or.jp
( ° )～日下部陽一
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

IIJIMA Hiromitsu

未読、

2003/05/09 7:06:432003/05/09

To:

いいじまです。

> > 他には Alpha や最近の SPARC が 64 ビットプロセッサですね。
>
> 最近? UltraSPARC は PentiumPro と同時期くらいじゃなかったですか?
> もうちょっと古いかな?
> ＃もっとも、いっちゃん最初のやつはバグってて 64bit ペケだったような。

あ、たしかにそのころでしたね。

＃でも当時は UltraSPARC を 32 ビットモードでしか使ってなかった。
＃メモリも 1GB しか積んでないし。
＃いまはそのホストからは離れたけど、いまは 64 ビットで使えるようになって
＃いるんだろうか…

Taku

未読、

2003/05/10 6:20:582003/05/10

To:

Nobuhiro Shibuyaさんの<3EBA63FF...@dd.iij4u.or.jp>に関する投稿です。
便乗で質問させて下さい。
RTCの時刻はUTCなのでしょうか？それともJSTでしょうか？
というのもBIOSで見える時刻は普通JSTにあわせてあります。
現在，FreeBSD4.8を使っていますが，システム時計もJSTにしています。
すると，UTCはどこにも使っていないような気がするのです。
何を使っても修正すれば良いだけの話なので良いとは思いますが，
正式？にはどうなのでしょうか？

=>] 2038-01-19 03:14:07 UTC
=>
=>の前後に「その時歴史は動いた」の瞬間がやってくるはずですよね。
=># 閏秒問題のため数秒の誤差があります。

最近調べた結果では，Unixの場合，1970年1月1日の午前0時(TAI)を
起点(epoch)としたUnix時間を使っており，これには閏秒が
ないので正確にはUTCとは22秒のずれができているはずです。

私のパソコンのRTCはUnix時間を刻んでいると考えたほうが良いのでしょうか？

■
□■ Taku q...@yahoo.co.jp
■□■ powered by Pentium Pro 200 with FreeBSD 4.8-RELEASE

Taku

未読、

2003/05/10 6:21:002003/05/10

To:

MOCHIDA Shujiさんの<ul8issl...@pine.yorie.netside.co.jp>に関する投稿です。

=> 今から 35 年前つうと 1968 年製、まだ動いてるんでしょうか..
=>＃ 2.11BSD とかで。
UNICSが生まれたのが1969年ですね。
FreeBSDはUNICSの直系ですが，遺伝子は持っていないことになっています。
#最近歴史を調べる機会があって，つい反応してしまいました。

NAKAMURA Kazushi

未読、

2003/05/10 9:43:532003/05/10

To:

In article <b9ijqa$9kp$1...@news522.nifty.com>
q...@yahoo.co.jp writes:
>RTCの時刻はUTCなのでしょうか？それともJSTでしょうか？
選べます。sysinstallでinstallする時に、RTCはUTC or local time?
と聞かれたでしょ。

>というのもBIOSで見える時刻は普通JSTにあわせてあります。
local time(JST)を選んだんですね。ならばJSTにしているはず。

>現在，FreeBSD4.8を使っていますが，システム時計もJSTにしています。
>すると，UTCはどこにも使っていないような気がするのです。
>何を使っても修正すれば良いだけの話なので良いとは思いますが，
>正式？にはどうなのでしょうか？

時差のことを気にしているのでしょうか？それならJSTになっている
ようです、という結論になります。

>=>] 2038-01-19 03:14:07 UTC
>=>の前後に「その時歴史は動いた」の瞬間がやってくるはずですよね。
>=># 閏秒問題のため数秒の誤差があります。

32bit intなtime_tがoverflowする「時」ですね。

>最近調べた結果では，Unixの場合，1970年1月1日の午前0時(TAI)を
>起点(epoch)としたUnix時間を使っており，これには閏秒が
>ないので正確にはUTCとは22秒のずれができているはずです。
>
>私のパソコンのRTCはUnix時間を刻んでいると考えたほうが良いのでしょうか？

TAIとUTCの定義を調べましょう。そして、それをOS(FreeBSD)がどう
扱っているかを。

UNIXでなくて、MINIXの話ですが、Andrew S. Tanenbaum教授の本には
しょっちゅう出て来ます。Internet & TCP/IP創世紀にも、ルーティング
やネーミングと並んでタイミング（時刻の扱い）の重要性を折に触れては
忠告していました。手元の本「分散オペレーティングシステム」では、
3章「分散システムにおける同期」として、P.115からOSに必要な天文学
の知識について述べています。とても面白いので是非一度、読んで見て
ください。こんな爆笑の出来るくらい面白い教科書なんて、この人と
ダグラス・カマーぐらいしか書けないですよ。目鱗間違い無し!
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.jp/>
- Be Free(BSD), or Die...

MOCHIDA Shuji

未読、

2003/05/11 11:49:312003/05/11

To:

持田＠NETside です。

> UNICSが生まれたのが1969年ですね。

PDP-7 は 1964 年の製品の様です。PDP-11 は 1970 年ですね。
1968 年以前製のマシンで現役 Unix は居なさそうですね。Multics が
現役で動いてるということはちらほら聞いたことがありますが、それの
ハードウエアはいつごろなんでしょうね。

> FreeBSDはUNICSの直系ですが，遺伝子は持っていないことになっています。

うーん、「遺伝子は持ってない」というのがどういうことを指すのか
わかりませんが、著作件的な攻撃にあう可能性が低い、ってこと以外に、
「Unix とかかわりが無い」なんて言えるんですかね? そういうの
よく見かけるけど、どういうことを意図してるんだかよく理解できません。
文化的な点は言うまでもないですが、例えば、

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/init_main.c?rev=1.230

には

| * Copyright (c) 1982, 1986, 1989, 1991, 1992, 1993
| * The Regents of the University of California. All rights reserved.
| * (c) UNIX System Laboratories, Inc.
| * All or some portions of this file are derived from material licensed
| * to the University of California by American Telephone and Telegraph
| * Co. or Unix System Laboratories, Inc. and are reproduced herein with
| * the permission of UNIX System Laboratories, Inc.

とかあるのは、どう思います?

ca...@kgc.co.jp

未読、

2003/05/11 19:08:302003/05/11

To:

q...@yahoo.co.jp (Taku) writes:

> RTCの時刻はUTCなのでしょうか？それともJSTでしょうか？
> というのもBIOSで見える時刻は普通JSTにあわせてあります。
> 現在，FreeBSD4.8を使っていますが，システム時計もJSTにしています。

> 私のパソコンのRTCはUnix時間を刻んでいると考えたほうが良いのでしょうか？

UNIX は、タイマ割り込みを使って、
独自に時刻管理(epoch からの秒数)しています。
FreeBSD では RTC を読むのは起動時くらいです。

あなたの RTC は JST に合わせてあって、
その情報は /etc/localtime に書かれていて、
FreeBSD は起動時にそれを見て、
カーネルの時計を初期設定します。

神田敏広 <ca...@kgc.co.jp>

nob Kurihara

未読、

2003/05/13 0:18:192003/05/13

To:

くりはらです

IIJIMA Hiromitsu wrote:
>>>他には Alpha や最近の SPARC が 64 ビットプロセッサですね。
>>
>> 最近? UltraSPARC は PentiumPro と同時期くらいじゃなかったですか?
>>もうちょっと古いかな?
>>＃もっとも、いっちゃん最初のやつはバグってて 64bit ペケだったような。
>
>
> あ、たしかにそのころでしたね。

一応1995,6年には UltraSPARC が出回っています。あとは、「最近」の定義だけで
すか :-)

saitoh akinori

未読、

2003/05/13 5:05:202003/05/13

To:

大阪大学の齊藤です

Taku wrote:
> Nobuhiro Shibuyaさんの<3EBA63FF...@dd.iij4u.or.jp>に関する投稿です。
> 便乗で質問させて下さい。
> RTCの時刻はUTCなのでしょうか？それともJSTでしょうか？

UNIXがRTCに対応したとき(VAX対応くらい？)、RTC=GMT(だかUTCだか
しらないが）として実装されました。UNIXの内部時計もGMTでしたし。

IBMPCに移植するときに、WindowsやDOSとのデュアルブートを行う
上で不都合が起こりました。
DOS/WindowsはRTC=ローカルタイムとして実装されていたから。

で、PCで動くUNIXは、RTCがローカルタイムであってもUTCであっても
どちらにも対応できるような機能が備わるようになりました。

というわけで、「IBMPCならJST,　他の機種ならばUTCが正しそう」
という答えになるのかなぁ。。

齊藤明紀　sai...@ist.osaka-u.ac.jp

Yasushi Shinjo

未読、

2003/05/13 5:11:302003/05/13

To:

新城＠筑波大学情報です。こんにちは。

In article <s7fel35...@xxx.kgc.co.jp>

ca...@kgc.co.jp writes:
> UNIX は、タイマ割り込みを使って、
> 独自に時刻管理(epoch からの秒数)しています。
> FreeBSD では RTC を読むのは起動時くらいです。

タイマ割込みの精度は、10ミリ秒くらいですよね。それより精度の
高い時計が得られることがあるのですが、それはどうやっているの
でしょうか。

うちの FreeBSD で clock_gettime() の CLOCK_REALTIME したら、
839 ナノ秒と出てきました。

Sun は、clock_gettime() では、10ミリ秒とは出てきますが、別に
gethrtime() というのかあります。

RTC って、Real Time Clock という意味ですか？

Followup-To: fj.unix としてあります。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

------------------------------------------------------------
#include <sys/time.h>

main()
{
struct timespec tp ;

clock_getres( CLOCK_REALTIME,&tp );
printf("tp.tv_sec: %u \n",tp.tv_sec );
printf("tp.tv_nsec: %u \n",tp.tv_nsec );
}
------------------------------------------------------------

Yasushi Shinjo

未読、

2003/05/13 5:29:092003/05/13

To:

新城＠筑波大学情報です。こんにちは。

In article <b9ijqa$9kp$1...@news522.nifty.com>

q...@yahoo.co.jp (Taku) writes:
> 最近調べた結果では，Unixの場合，1970年1月1日の午前0時(TAI)を
> 起点(epoch)としたUnix時間を使っており，これには閏秒が
> ないので正確にはUTCとは22秒のずれができているはずです。
>
> 私のパソコンのRTCはUnix時間を刻んでいると考えたほうが良いのでしょうか？

ＰＣのハードウェアが保持している時刻は、起点からの秒数ではな
くてカレンダーの形式で取れるようになっているんじゃないですか
ね。ＯＳとは関係なく。Unix が起動する時には、カレンダー形式
の時計(2003/05/13 18:17:38 のようなもの)を読込んで、それを
Unix の内部的な時計に変換していると。

詳しい人の突っ込みお願いします。

In article <b9ijqa$9kp$1...@news522.nifty.com>

q...@yahoo.co.jp (Taku) writes:
> RTCの時刻はUTCなのでしょうか？それともJSTでしょうか？
> というのもBIOSで見える時刻は普通JSTにあわせてあります。
> 現在，FreeBSD4.8を使っていますが，システム時計もJSTにしています。
> すると，UTCはどこにも使っていないような気がするのです。
> 何を使っても修正すれば良いだけの話なので良いとは思いますが，
> 正式？にはどうなのでしょうか？

Time Zone は、どちらでもいいんじゃないですか。BIOS と OS (複
数かもしれない)で、つじつまが合っていれば。

ＰＣのハードウェアが持っている時計に閏秒を刻む機能があるとは
思えません。そういう設定は、BIOS にはないですよね。それで困
るかというと、全然困らないと思います。閏秒が出たら、単純にＯＳ
側から（シャットダウンする時にでも）設定すればいいので。

Yasushi Shinjo

未読、

2003/05/13 5:48:222003/05/13

To:

新城＠筑波大学情報です。こんにちは。

In article <ul8y91i...@pine.yorie.netside.co.jp>
MOCHIDA Shuji <moc...@netside.co.jp> writes:
> 持田＠NETside です。

> time_t が 64bit でちゃんと動く OS が載ってれば、32bit アーキテクチャでも
> 2038 年以降も大丈夫だと思いますよ。

そうでもないです。というのも、ハードディスクとか CD-ROM とか、
記憶媒体に保存されたデータを 2038年に瞬時に書き換えることが
できないので。コピーするにしても、長いもの短いもの両方の体系
に対応する必要がありますが、これには time_t のビット数を変え
ただけでは対応できません。

同じような意味で、2000年問題も、まだ完全には終っていません。
昔の電子メールのデータで日付が２桁のものがあったりして、そう
いうデータを１００年くらいたった後で使うときにどう解釈すれば
いいかという話が残っています。

In article <KATE.03M...@flash.tokyo.pfu.co.jp>

ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:
> > Alpha や UltraSPARC だと割と落ちてませんか?(笑)
> あと 35 年も壊れずに動き続けられるとは思えないんですが、、、:-p

2000年問題の時にも、そんな事を言ってましたね。このプログラム
がそんなに長く使われるとは思わなかったって。あれは後付の理由
なんでしょうね。正確には「プログラム書く時にいつまで使うかを
何も考えてなかった」ということでしょう。

Nagata

未読、

2003/05/13 6:52:372003/05/13

To:

ながたです。ほとんど茶々ですが m(..)m

☆Subject: the End of 32-bit time_t

In article <YAS.03Ma...@kirk.is.tsukuba.ac.jp>
>> 新城＠筑波大学情報です。こんにちは。

>> > 持田＠NETside です。
>> > time_t が 64bit でちゃんと動く OS が載ってれば、32bit アーキテクチャでも
>> > 2038 年以降も大丈夫だと思いますよ。

>> そうでもないです。というのも、ハードディスクとか CD-ROM とか、

単純に、ゼロパディングして自動拡張すれば？と思いきや、
たとえば ufs も time_t は 32bit みたいですね。

＃ 64bit 2038 ufs solaris で yahoo.com しても問題がある
＃話しか見つからないみたい。

諦めて int を 64bit にしてしまうと、古いディスクとか
まったく読めなくなりそうですし。読み込みツールも大変そう。
＃ＯＳ屋さん、大変ですね。inode コンバータ？
＃３０年以上動くシステム提案では、time_t 要チェックですか...(汗)

tar とか dump で吸収して変換するなら簡単かも。２台用意する。
＃ 64bit バージョンの tar とか出るのでしょう。もうある？

>> 昔の電子メールのデータで日付が２桁のものがあったりして、そう
>> いうデータを１００年くらいたった後で使うときにどう解釈すれば
>> いいかという話が残っています。

2069年以降、西暦を２桁で扱うシステムを法的に禁止すれば
なんとかなるかも？

＃２桁表記だったら、無条件に 70-69 -> 1970-2069 に変換 (^^;

じゃないと、「予算がない～」とかいって古いシステムの
まま済まそうとする所が絶対でてシステム屋さんが苦労する。

＃その頃私はあの世ですが、今学生な人は注意しましょう :-p

メールならこれでいいですが誕生日データとかはアウトです。
＃ってそれはもう対応済ですね。

Nagata

未読、

2003/05/13 7:03:282003/05/13

To:

でも良く考えたら、ちゃんと unsigned 対応さえしてれば
2106 年あたりまで問題ないということで、みんな
知らん顔で済ましそう (^^;

In article <b9qipl$11s$1...@caraway.media.kyoto-u.ac.jp>
>> ながたです。ほとんど茶々ですが m(..)m

>> >> > 2038 年以降も大丈夫だと思いますよ。

>> 単純に、ゼロパディングして自動拡張すれば？と思いきや、
>> たとえば ufs も time_t は 32bit みたいですね。

これを64bit にするのは「ものすごく」大変ですから。
＃真剣に動きだすのは、2080 年頃とみた。

Taku

未読、

2003/05/13 8:31:172003/05/13

To:

MOCHIDA Shujiさんの<ul8k7cx...@pine.yorie.netside.co.jp>に関する投稿です。

=>| * Copyright (c) 1982, 1986, 1989, 1991, 1992, 1993
=>| * The Regents of the University of California. All rights reserved.
=>| * (c) UNIX System Laboratories, Inc.
=>| * All or some portions of this file are derived from material licensed
=>| * to the University of California by American Telephone and Telegraph
=>| * Co. or Unix System Laboratories, Inc. and are reproduced herein with
=>| * the permission of UNIX System Laboratories, Inc.
非常に面白い文章です。
著作権が問題になりその部分を完全に取り除いた4.4BSD-Liteがでたのが
1994年なので，もし，

が著作権の更新年のようなものを表すのであれば
4.4BSD-Lite以前のもので，それは事実です。
法律の専門家でないので

の意味をどなたか教えていただければありがたいです。

MOCHIDA Shuji

未読、

2003/05/13 11:20:282003/05/13

To:

持田＠NETside です。

> そうでもないです。というのも、ハードディスクとか CD-ROM とか、

:

> に対応する必要がありますが、これには time_t のビット数を変え
> ただけでは対応できません。

それはもちろんそうなのですが、元の話を「ハードウエアの 64bit の
サポートがほしい」と取ったので、ああ書いたまでです。

> 同じような意味で、2000年問題も、まだ完全には終っていません。
> 昔の電子メールのデータで日付が２桁のものがあったりして、そう
> いうデータを１００年くらいたった後で使うときにどう解釈すれば
> いいかという話が残っています。

こういうの含めてですが、

> 2000年問題の時にも、そんな事を言ってましたね。このプログラム
> がそんなに長く使われるとは思わなかったって。あれは後付の理由
> なんでしょうね。正確には「プログラム書く時にいつまで使うかを
> 何も考えてなかった」ということでしょう。

書いた人も、検収した人も「そこまで使われない」と思っていたんだとしたら、
捨てればいいと思うんですよね(*)。それが筋かと。今使ってる人が、
「作った奴がいつまで使うか考えてなかった、思慮が浅い」って言うのは
何か変な気がします。

＃ (*) と 2000 年の時にここら付近で言ってみたらフォロー付かなかった
＃覚えがあります。

ということで、責任持って 2038 年かの日以後は起動できいように、
今から作っとけばいいかな。

MOCHIDA Shuji

未読、

2003/05/13 11:49:252003/05/13

To:

持田＠NETside です。

> 4.4BSD-Lite以前のもので，それは事実です。

いや、そんなことが言いたいんじゃなくて..

UNIX の版権持った人に侵害を申し立てられる可能性のほとんどない、
AT&T 由来のファイルがいくつかあります。まあ、中身はたいした内容じゃ
ないか、ほとんど完全に書き変わっているものばかりですけど。

そんなことより、なんでそんなに著作権で切れ目を作りたいのか
よくわからないです。
＃商利用したり、再配布したりするのなら著作権に気を付ける必要は
＃ありますけど。

4.4BSD(無印) と 4.4BSD-Lite、4.4BSD-Lite2 と FreeBSD 5.0 の違いより、
32/V と 4BSD の方がずっと「違う」と思うけどなぁ。

Nobuhiro Shibuya

未読、

2003/05/13 12:15:432003/05/13

To:

渋谷@家からです

MOCHIDA Shuji wrote:

> 持田＠NETside です。

> ということで、責任持って 2038 年かの日以後は起動できいように、
> 今から作っとけばいいかな。

32-bit time_t のオーバーフローをトリガにしたアポトーシスを
実現するシステムコールを実装、ですか。
ソーシャル・エンジニアリングの領域ですよね？
財産はもちろん人命、果ては地球の命運に関わる場合まで含めて
起動できないという一点張りで押し通せるならそれも可かなあ。

MOCHIDA Shuji

未読、

2003/05/13 23:45:522003/05/13

To:

持田＠NETside です。

>> たとえば ufs も time_t は 32bit みたいですね。

>> tar とか dump で吸収して変換するなら簡単かも。２台用意する。

「使えなく」してしまうのがよいかと。デフォルトでは Read Only でしか
マウントできなくする。「もうすぐ使えなくなるよ～」ってあらかじめ
宣伝しておいて、その後で Read Only にして、移行を促す。
両方で 2 年もあれば十分じゃないでしょうか。
＃組み込みモンは... 捨てる。(笑)

...やっぱ、5 年くらいはかかるかな..

> でも良く考えたら、ちゃんと unsigned 対応さえしてれば
> 2106 年あたりまで問題ないということで、みんな
> 知らん顔で済ましそう (^^;

2000 年の時みたいに多数が直前まで無頓着だと、そうなるかも知れませんね。

>>> たとえば ufs も time_t は 32bit みたいですね。

> これを64bit にするのは「ものすごく」大変ですから。

そうかなぁ? ちゃんと判別さえ出来ればそんな大変じゃないような
気がしますが。

MOCHIDA Shuji

未読、

2003/05/13 23:50:462003/05/13

To:

持田＠NETside です。

> 32-bit time_t のオーバーフローをトリガにしたアポトーシスを
> 実現するシステムコールを実装、ですか。

いや、そこまでやらなくても.. プログラムの先頭でメッセージ出して
終ればいいと思います。

過ぎていることを検出できないといけないので、その部分は用意しないと
ダメですけど。
＃ファームウエアがダメなら不可能ですね。

ので、

> ソーシャル・エンジニアリングの領域ですよね？

そんなたいそうなことじゃないかと。

Nagata

未読、

2003/05/14 1:51:232003/05/14

To:

ながたです。

システムだと話が広範になるので ufs とか周り限定。

☆Subject: Re: the End of 32-bit time_t

In article <ul8smri...@pine.yorie.netside.co.jp>
>> 持田＠NETside です。

>> 「使えなく」してしまうのがよいかと。デフォルトでは Read Only でしか
>> マウントできなくする。

なるほど。

>> > これを64bit にするのは「ものすごく」大変ですから。
>>
>> そうかなぁ? ちゃんと判別さえ出来ればそんな大変じゃないような
>> 気がしますが。

NFSは？ mmap は、とかぐたぐた２０行文章書いてて、ハタと

旧ファイルシステムのマウント機能を独立に用意して、(mount_pcfs とか
みたいに？) システムコールレベルでtimestamp を 32->64 ビットに
変換すれば、なんとなく実現できそうに思えてきました。

以下、ゴミ＆妄言。

勝手に予想。その名も ufs64

#pragma ident "@(#)ufs64_fs.h 0.00 2021/01/13 SMI" /* SVr7.0 0.0 */
おぃ

ps

そういうOSが出るまで SunOS4 でねばろう :-p

saitoh akinori

未読、

2003/05/14 6:12:302003/05/14

To:

大阪大学の齊藤です

Taku wrote:
> 著作権が問題になりその部分を完全に取り除いた4.4BSD-Liteがでたのが
> 1994年なので，もし，

「その部分を完全に取り除いた」という言葉を誤解してるのでは？

USLと和解交渉で、「この部分は含めることはまかりならん」
とUSLが主張した部分を取り除いただけであって、AT&T由来コードを
100%取り除いたわけではないということ。

齊藤明紀 sai...@ist.osaka-u.ac.jp

ku...@gssm.otsuka.tsukuba.ac.jp

未読、

2003/05/14 7:38:362003/05/14

To:

久野です。

sai...@ics.es.osaka-u.ac.jpさん:

> USLと和解交渉で、「この部分は含めることはまかりならん」
> とUSLが主張した部分を取り除いただけであって、AT&T由来コードを
> 100%取り除いたわけではないということ。

どんな場所をどいういう理由で「まかりならん」と言ったのか分かり
ます?

単につけられるだけ因縁つけたってわけじゃないよね? 久野

NAKAMURA Kazushi

未読、

2003/05/14 9:57:492003/05/14

To:

In article <b9t9rs$1q...@utogw.gssm.otsuka.tsukuba.ac.jp>

それに近いのでは。かつて、4.4BSDから該当部分を取り除いて、代替
コードの間に合った部分を追加した4.4BSD-Liteや-Lite2を出した時、
そのコード品質が低い理由として「かつてAT&Tのコードを見ることが
出来た人が書いたコードもAT&Tの著作物とみなす」と主張されたので、
AT&Tのコードを見たはずも無い新入生に書かせたから勘弁してちょ、
みたいな言い訳を見たような。

当時、NetBSDな人だったんですが、NetBSD0.9->1.0で安定度が「かなり」
落ちたので、0.9な時代が結構長く続きました。NetBSD0.9とても安定して
いて良かったのですがね。uptimeサイトの上位best5くらいをNetBSDが
独占していました。3000days以上稼働しているサイトも有ったような。
netcraftのrankingに載ってたと思ったけど…、違ったっけ？

ca...@kgc.co.jp

未読、

2003/05/15 17:54:132003/05/15

To:

y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:

> タイマ割込みの精度は、10ミリ秒くらいですよね。それより精度の
> 高い時計が得られることがあるのですが、それはどうやっているの
> でしょうか。
>
> うちの FreeBSD で clock_gettime() の CLOCK_REALTIME したら、
> 839 ナノ秒と出てきました。

FreeBSD i386 だと、
CPU 内蔵の TSC (time stamp counter) や i8254 を読みます。
i8254 は 1193128Hz なので、838 nsec の精度ですね。

ntpd(8) がらみでよくでてくる
options CLK_USE_I8254_CALIBRATION
options CLK_USE_TSC_CALIBRATION

例<URL:http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/69506>

とかは、起動時にこれらのカウンタを実測して、
個体ごとのバラツキを吸収し、時刻の精度を高めようというものです。

神田敏広 <ca...@kgc.co.jp>

Taku

未読、

2003/05/16 3:31:412003/05/16

To:

candyさんの<s7fel35...@xxx.kgc.co.jp>に関する投稿です。

=>UNIX は、タイマ割り込みを使って、
=>独自に時刻管理(epoch からの秒数)しています。
=>FreeBSD では RTC を読むのは起動時くらいです。
=>
=>あなたの RTC は JST に合わせてあって、
=>その情報は /etc/localtime に書かれていて、
=>FreeBSD は起動時にそれを見て、
=>カーネルの時計を初期設定します。
実はこの疑問が生じたのは，OSの時刻とBIOSの時刻が違うからです。
現在ntpdを起動させていて，OSの時刻はJSTにぴったりあっているはずです。
一方BIOSの時刻は先日時報と比べてみると0.5秒ぐらいずれています。
私の機械の場合，起動時にRTCの時刻を読んだ後にntpdで正確な時刻に
あわせられているということですね。

ここで，OSからRTCへ時刻を書きこむ方法はないでしょうか？
FreeBSDのMLなどを読むとcronが自動的に書きこんでくれるようなことを
書いてあるのですが，実際にはそうではないようです。
なお，ntpd起動の前にntpdateを起動して時刻をあわせています。

Taku

未読、

2003/05/16 3:31:392003/05/16

To:

NAKAMURA Kazushiさんの<0305102243...@ns.kobe1995.net>に関する投稿です。

=>UNIXでなくて、MINIXの話ですが、Andrew S. Tanenbaum教授の本には
=>しょっちゅう出て来ます。Internet & TCP/IP創世紀にも、ルーティング
=>やネーミングと並んでタイミング（時刻の扱い）の重要性を折に触れては
=>忠告していました。手元の本「分散オペレーティングシステム」では、
=>3章「分散システムにおける同期」として、P.115からOSに必要な天文学
=>の知識について述べています。とても面白いので是非一度、読んで見て
=>ください。こんな爆笑の出来るくらい面白い教科書なんて、この人と
=>ダグラス・カマーぐらいしか書けないですよ。目鱗間違い無し!
アマゾンで調べたらビックリ価格です。
もう少し，安い本があるとありがたいのですか。

NAKAMURA Kazushi

未読、

2003/05/17 8:18:012003/05/17

To:

中村和志＠神戸です。

In article <ba244t$sgk$2...@news522.nifty.com>

q...@yahoo.co.jp writes:
>=>UNIX は、タイマ割り込みを使って、
>=>独自に時刻管理(epoch からの秒数)しています。
>=>FreeBSD では RTC を読むのは起動時くらいです。
>=>
>=>あなたの RTC は JST に合わせてあって、
>=>その情報は /etc/localtime に書かれていて、
>=>FreeBSD は起動時にそれを見て、
>=>カーネルの時計を初期設定します。
>実はこの疑問が生じたのは，OSの時刻とBIOSの時刻が違うからです。
>現在ntpdを起動させていて，OSの時刻はJSTにぴったりあっているはずです。
>一方BIOSの時刻は先日時報と比べてみると0.5秒ぐらいずれています。
>私の機械の場合，起動時にRTCの時刻を読んだ後にntpdで正確な時刻に
>あわせられているということですね。

そうです。

>なお，ntpd起動の前にntpdateを起動して時刻をあわせています。

これは正しい、と言うか一般的な流儀です。ntpdは、一気に時刻を合わせる
ようなことはせず、kernel PLL(software的に実装したPLL発振器／タイマ)
を微妙に進めたり、遅らせたりして、徐々に時刻を合わせています。でないと
突然時刻がワープすると困るアプリケーションが存在しますので。
ところが、誤差が余り大きいと徐々に合わせていられなくて、ntpd
がgive upしてしまいます。なので起動時にntpdateで一気に合わせてしまって
それ以降はntpdで、時刻がワープすることのないよう、かつ誤差が余り
大きくならないように微妙にkernel PLLを調整して時刻を合わせるのが
一般的なUNIXのやり方ですね。

別スレッドになりつつある、RTC chipを越えた精度も kernel PLL
の御蔭です。と言っても私も詳しくは追い掛けていないのですが、
興味を持たれたら、件の本に挙げられている参考文献や、手元に有る
sourceを読んで見てください。Pentium以降のperformance counter
を使えば、μsを切ってnsの精度が得られるかも、これってナノテク？
…と思っているのですが、そこまで手が回っていません。

>ここで，OSからRTCへ時刻を書きこむ方法はないでしょうか？
>FreeBSDのMLなどを読むとcronが自動的に書きこんでくれるようなことを
>書いてあるのですが，実際にはそうではないようです。

惜しい!MLやmanのハシゴだけでなく、たまには file system tree
もたぐってみましょう。cronまで分かったのなら、/etc/crontab
を見て、
adjkerntz
というのが見付かっていた訳。惜しい!

Nobuhiro Shibuya

未読、

2003/05/17 9:05:002003/05/17

To:

渋谷@家からです

NAKAMURA Kazushi wrote:

> 中村和志＠神戸です。

> これは正しい、と言うか一般的な流儀です。ntpdは、一気に時刻を合わせる
> ようなことはせず、kernel PLL(software的に実装したPLL発振器／タイマ)
> を微妙に進めたり、遅らせたりして、徐々に時刻を合わせています。でないと
> 突然時刻がワープすると困るアプリケーションが存在しますので。

Solaris 2.2 (SunOS5.2)だったかの date がこの流儀で時計あわせを
してくれたのを思い出しました。
SunOS4.xとかNEWS-OS 4.x ではクラシカルかつ大雑把なdateでした。

syslogの時間が昇順でなくなるのが嫌だったからこれはいける
とおもったのだったけな。

Taku

未読、

2003/05/18 1:46:502003/05/18

To:

NAKAMURA Kazushiさんの<0305172118...@ns.kobe1995.net>に関する投稿です。

=>>私の機械の場合，起動時にRTCの時刻を読んだ後にntpdで正確な時刻に
=>>あわせられているということですね。
=>そうです。
=>
=>>なお，ntpd起動の前にntpdateを起動して時刻をあわせています。
=>
=>これは正しい、と言うか一般的な流儀です。ntpdは、一気に時刻を合わせる
=>ようなことはせず、kernel PLL(software的に実装したPLL発振器／タイマ)
=>を微妙に進めたり、遅らせたりして、徐々に時刻を合わせています。でないと
=>突然時刻がワープすると困るアプリケーションが存在しますので。
=>ところが、誤差が余り大きいと徐々に合わせていられなくて、ntpd
=>がgive upしてしまいます。なので起動時にntpdateで一気に合わせてしまって
=>それ以降はntpdで、時刻がワープすることのないよう、かつ誤差が余り
=>大きくならないように微妙にkernel PLLを調整して時刻を合わせるのが
=>一般的なUNIXのやり方ですね。
有難うございました。
調べて理解したことが正しいことがわかりました。
#WebPageやMLも正しいことが書いてあるとは限らないので

=>別スレッドになりつつある、RTC chipを越えた精度も kernel PLL
=>の御蔭です。と言っても私も詳しくは追い掛けていないのですが、
=>興味を持たれたら、件の本に挙げられている参考文献や、手元に有る
=>sourceを読んで見てください。Pentium以降のperformance counter
=>を使えば、μsを切ってnsの精度が得られるかも、これってナノテク？
=>…と思っているのですが、そこまで手が回っていません。
これはちょっと私の手にあまるようです。

=>>ここで，OSからRTCへ時刻を書きこむ方法はないでしょうか？
=>>FreeBSDのMLなどを読むとcronが自動的に書きこんでくれるようなことを
=>>書いてあるのですが，実際にはそうではないようです。
=>惜しい!MLやmanのハシゴだけでなく、たまには file system tree
=>もたぐってみましょう。cronまで分かったのなら、/etc/crontab
=>を見て、
=> adjkerntz
=>というのが見付かっていた訳。惜しい!
crontabのこの行を見つけて書き直しました。
31 0-23 * * * root adjkerntz -a
24時間一時間に一回あわせるようにしました。
FreeBSDはサーバー用なのか，夜も動くことが前提のようで
crontabはかならず書き替えておかないと，私のような昼型人間の
マシンは永久にperiodicもadjkerntzも動かずに終ってしまいそうです。

有難うございました。
長年の疑問が解けました。

Shinji KONO

未読、

2003/05/18 2:45:522003/05/18

To:

河野真治 @ 琉球大学情報工学です。

In article <0305172118...@ns.kobe1995.net>, k...@kobe1995.net (NAKAMURA Kazushi) writes
> 突然時刻がワープすると困るアプリケーションが存在しますので。

もし、それが本当なら、ノートPCのサスペンドから復旧したときに、
それらは全滅ですね。

で、BSD/OS で実際、サスペンドの時に「ゆっくり時刻を合わせる」
ってのがあってさ、これで、
cron がものすごい勢いで実行される
という目にあったことがあって、「そりゃだめだ... 」と
思ったことがあります。

nptdate にも一気に合わせるオプションがあって僕はそれを
使っているな。

っていうわけなので、ワープすると困るアプリケーションってのは
都市伝説なのではないかと思います。

なんかSun OSで時計のバグがあってUnixの時刻がふらふら動く
なんてのがあったなぁ。

> adjkerntz
> というのが見付かっていた訳。惜しい!

おぉ、それははじめて見た。

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)

Taku

未読、

2003/05/18 7:31:272003/05/18

To:

Shinji KONOさんの<3988364...@insigna.ie.u-ryukyu.ac.jp>に関する投稿です。

=>nptdate にも一気に合わせるオプションがあって僕はそれを
=>使っているな。
=>
=>っていうわけなので、ワープすると困るアプリケーションってのは
=>都市伝説なのではないかと思います。
小規模システムではそうですが，大規模のシステム，例えば
ISPのメールサーバーなんかはワープすると大変だと思います。

同じタイムスタンプで実時間のことなるメールが発信されたり，
クライアント側には大きな問題ではないような気がしますが，
サーバー側ではそうでないような気がします。
　　　　　　↑
　　「ワープしたら困る」の説明に良く使われている例です。

Shinji KONO

未読、

2003/05/18 7:56:112003/05/18

To:

河野真治 @ 琉球大学情報工学です。

In article <ba7quf$18k$2...@news521.nifty.com>, q...@yahoo.co.jp (Taku) writes

> 同じタイムスタンプで実時間のことなるメールが発信されたり，
> クライアント側には大きな問題ではないような気がしますが，
> サーバー側ではそうでないような気がします。
> 　　　　　　↑
> 　　「ワープしたら困る」の説明に良く使われている例です。

一旦未来にいってしまったものを引き戻すのに、ちょっと遅くする
ってのはありかな。

メールサーバで困るのは時間が遡った時ですよね。徐々に時間が遡
ったりしたら最低だ... ただ、時間だけのタイムスタンプなんての
を使うこと自体がだめだめな気はしますね。通し番号が別に入って
いれば、時間がさかのぼっても問題ない。

BSD/OSは、時間を戻すのを禁止するコードが入っていて最低でした。
結局、パッチ当てて解除したっけ。

一回はまったのは、Solaris 2.6 でY2Kのテストで2000年に時計を
進めて戻したときだな。socket のtimeout remove が動かなくなっ
たらしくって、port が足りなくなってネットワークが死んでしま
いました。

ca...@kgc.co.jp

未読、

2003/05/18 20:11:292003/05/18

To:

q...@yahoo.co.jp (Taku) writes:

> =>>ここで，OSからRTCへ時刻を書きこむ方法はないでしょうか？
> =>>FreeBSDのMLなどを読むとcronが自動的に書きこんでくれるようなことを
> =>>書いてあるのですが，実際にはそうではないようです。
> =>惜しい!MLやmanのハシゴだけでなく、たまには file system tree
> =>もたぐってみましょう。cronまで分かったのなら、/etc/crontab
> =>を見て、
> => adjkerntz
> =>というのが見付かっていた訳。惜しい!

adjkerntz -a では、タイムゾーンが変わったりしない限り、
RTC (CMOS クロック) は書き変わりません。

つーか、adjkerntz(8) に書いてある
| -i で SIGTERM を受けた時に CMOS を書き換える
というのも、私が知る限りは正しく機能したことありません。
(だから起動時に ntpdate -sbv とかのお世話になる必要がある)

てなわけで、

> 24時間一時間に一回あわせるようにしました。

これは
<URL:http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/69921>
のプログラムを一日一度走らせるのがいいようです。
(return 0; くらいはあった方がいいかも)
うちは実際にこれを走らせています。
おかげさまで、uptime 128 days なマシン
(<URL:http://www.tochigi.com/ntp/>)
でも

gettimeofday = 09:07:42
RTC = 09:07:42

です。

神田敏広 <ca...@kgc.co.jp>

ca...@kgc.co.jp

未読、

2003/05/18 20:21:282003/05/18

To:

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

> 一回はまったのは、Solaris 2.6 でY2Kのテストで2000年に時計を
> 進めて戻したときだな。socket のtimeout remove が動かなくなっ
> たらしくって、port が足りなくなってネットワークが死んでしま
> いました。

Windows ですが、
とあるシステムのキューも、タイムアウト管理を時計に依存してたので、
SNTP クライアントがバキッと時間を戻すと、
それだけでロックしてしまいました。

時間が逆流すると、make(1) はかなり戸惑いますね。

また時間がものすごく遅れている時も、
百万回 make してもターゲットが作れないとかたまにあります。

神田敏広 <ca...@kgc.co.jp>

MOCHIDA Shuji

未読、

2003/05/19 1:25:412003/05/19

To:

持田＠NETside です。

>> USLと和解交渉で、「この部分は含めることはまかりならん」

> どんな場所をどいういう理由で「まかりならん」と言ったのか分かり
> ます?

sys/kern/init_main.c については、Net/2 では UC のみの Copyright が
付いています。Net/1 にはこれに該当するファイルは含まれません。
UC 側は init_main.c は完全に書き変わっている、もしくは単純な内容で
誰が書いても似たようなもの、等の理由で、著作権侵害を主張できる可能性が
低いと、Net/2 の時点では考えていたのではないでしょうか。

USL が「これはウチのコードがベースだ。これについては出していいが、
ウチの名前入れろ」と言ったのではないでしょうか?

> 単につけられるだけ因縁つけたってわけじゃないよね? 久野

それに近いんではないでしょうか。

和解に至ったのは、結局 SystemV に含まれる UCB のコードに対する
Copyright が明記されていないという対抗訴訟を起こされたからですよね?
BSD ライセンスのあの項がなければ、4.4BSD-Lite は無かったかも知れない。
＃ Net/2 はごく最近まで本当に「無かった」も同然でしたし。

saitoh akinori

未読、

2003/05/22 10:28:312003/05/22

To:

大阪大学の齊藤です

ku...@gssm.otsuka.tsukuba.ac.jp wrote:
> 久野です。

>>USLと和解交渉で、「この部分は含めることはまかりならん」
>>とUSLが主張した部分を取り除いただけであって、AT&T由来コードを
>>100%取り除いたわけではないということ。
> どんな場所をどいういう理由で「まかりならん」と言ったのか分かり
> ます?

確か、和解内容は非公開だったはずで、よくわからない。
UCBが、「これは我々がスクラッチから書いたコードだ」と
みなしてNet/2で公開した者に対して、「USLの権利が及ぶ」と
主張したのには違いないのだが。。。

外部からわかるのは、4.4BSD/Liteで、physio.cとかacct.cとか、
５個のファイルが削除されたことなどだけですね。

あと、調べたらわかると思うけど、USLのcopyrightが追加されて
4.4BSD-Liteに含まれているところも文句が付いたところでしょう。

齊藤明紀 sai...@ist.osaka-u.ac.jp

ku...@gssm.otsuka.tsukuba.ac.jp

未読、

2003/05/22 20:23:412003/05/22

To:

久野です。

sai...@ics.es.osaka-u.ac.jpさん:
> 確か、和解内容は非公開だったはずで、よくわからない。

非公開だったんですね。しかし何年もたっているわけで、歴史的文書
みたいにいつかは公開して欲しい気も。

> UCBが、「これは我々がスクラッチから書いたコードだ」とみなして
> Net/2で公開した者に対して、「USLの権利が及ぶ」と主張したのには
> 違いないのだが。。。

話の筋としてはそうでしょうけど論拠が分からないですからね。

> 外部からわかるのは、4.4BSD/Liteで、physio.cとかacct.cとか、
> ５個のファイルが削除されたことなどだけですね。
>
> あと、調べたらわかると思うけど、USLのcopyrightが追加されて
> 4.4BSD-Liteに含まれているところも文句が付いたところでしょう。

ああなるほど。してみると削除とcopyright追加との線引きなんかも
謎ですね。

単純に「程度の問題」ということ? 久野

MOCHIDA Shuji

未読、

2003/05/22 21:12:512003/05/22

To:

持田＠NETside です。

> そのコード品質が低い理由として「かつてAT&Tのコードを見ることが
> 出来た人が書いたコードもAT&Tの著作物とみなす」と主張されたので、
> AT&Tのコードを見たはずも無い新入生に書かせたから勘弁してちょ、
> みたいな言い訳を見たような。

そうだとすると

http://www.jp.netbsd.org/People/CSRG-contrib.html

あたりに名前のあがってる人なんかほとんどアウトになっちゃうと思うので、
少なくとも和解後は大丈夫になったんでしょうね。

> いて良かったのですがね。uptimeサイトの上位best5くらいをNetBSDが
> 独占していました。3000days以上稼働しているサイトも有ったような。

1.1B の sparc だったか、長いこと一位に居た覚えはあります。4 年くらいじゃ
なかったかな。3000 日だと、8 年 2 ヵ月... 0.9 は 1993 年なので、
直後からとしても 2001 年まであがってたことになります..

MAEDA Atusi

未読、

2003/05/23 6:49:322003/05/23

To:

ku...@gssm.otsuka.tsukuba.ac.jp writes:

> sai...@ics.es.osaka-u.ac.jpさん:
> > 確か、和解内容は非公開だったはずで、よくわからない。
>
> 非公開だったんですね。しかし何年もたっているわけで、歴史的文書
> みたいにいつかは公開して欲しい気も。

ちょうどSCOとの訴訟がらみでこんな記事がありました．
http://japan.cnet.com/news/pers/story/0,2000047682,20054524,00.htm

: 90年代前半には、今回とよく似たケースがあり、オープンソースOSにUnixから
: 盗まれたコードが使われているとの訴えが法廷闘争にまで発展したことがあっ
: た。このときはAT&Tが、カリフォルニア大学を相手に、同大学で開発したBSD
: がAT&Tの持つUnix関連の著作権を侵害したと訴えた。最終的には、AT&Tの主張
: が当てはまる箇所が、実はたった4カ所しかないことを法廷が突き止め、大学
: 側は論争を続ける代わりに、さっさと該当箇所を別のコードに書き換えてしまっ
: た。結局AT&Tは、裁判にかかった費用を支払うことで大学側と和解した。

日本語では曖昧ですが，原文では "AT&T then settled the case by paying the
university's court costs." となっており，支払ったのはAT&T側だそうです．

これが正確かどうかはわかりません．
http://www.openresources.com/documents/open-sources/node32.html
の最後には，
: The result was that three files were removed from the 18,000 that made
: up Networking Release 2, and a number of minor changes were made to
: other files. In addition, the University agreed to add USL copyrights
: to about 70 files, although those files continued to be freely
: redistributed.

とあります．費用云々については見つかりませんでした．

UCBといっしょに訴えられたBSDIの，和解に関するアナウンス
http://www.daemon.org/bsd-releases/misc/USL-lawsuit
には確かに「その他の和解内容については非公開」とありますね．

前田敦司

Yasushi Shinjo

未読、

2003/05/24 6:51:262003/05/24

To:

新城＠筑波大学情報です。こんにちは。

In article <m33cj6u...@maedapc.cc.tsukuba.ac.jp>
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> writes:
> ちょうどSCOとの訴訟がらみでこんな記事がありました．
> http://japan.cnet.com/news/pers/story/0,2000047682,20054524,00.htm

面白い記事ですね。
エキスパートの視点：Linuxに対して仕掛けられた心理戦
Bruce Perens
マクイロソフトが Unix のソースコードのライセンスを取って脅し
に使おうとしている、というのが最後の話なのですが、途中の
次の部分が特に面白かったです。
------------------------------------------------------------
　それでもSCOの幹部は、実のある証拠は何も見せないままで、自
分たちの著作権で保護されたコードがLinuxに流用されたと言い立
てている。
...
　すでに世間に出回っている、Linuxのソースコードを収録した無
数のCDのなかから、問題となりそうな箇所をきれいさっぱりと消し
てしまえる。McBrideの言い草だと、まるでそんなことが可能みた
いに聞こえる。
------------------------------------------------------------

「この部分がコピーされたと場所を示せば、証拠隠滅されるから示
せない」と SCO が主張しているけれど、証拠隠滅は無理です。
で、既にコピーされているから、いまさらその部分を公開しても、
SCO にとっては、これ以上損はしないはずなんだけど、公開しない。
ということは、SCO は、何の根拠は持っていない、という推論です。

In article <x765o5g...@maiorica.uni.sony.co.jp>
l...@uni.sony.co.jp writes:
> 佐藤通敏です。
> SCOは2001年5月にNovellからスピンアウトしたLinuxデストリビュータの
> Calderaに買収されました。
> http://www.caldera.com/

そんなニュースも聞いた気もするし、

In article <baf8nm$2qgl$1...@maha2.doga.co.jp>
Masamichi Takatsu <ta...@doga.jp> writes:
> 高津@ドーガです。
> 正確には、SCO のUNIX部門をCalderaが買収です。それと共に、残りの SCO は
> Tarantella に社名変更し、Caldera は2002年8月に SCO に社名を変更しています。
> でもって、今回の訴訟騒ぎはCalderaが社名変更した新しいSCO社が起こした
> ものですね。

そんなニュースも聞いた気もするけれど、すっかり忘れていました。

Subject: の case は、「訴訟」の意味です。この間、テレビの字
幕か同時通訳で、「場合」と訳していたんだけれど、そういうのを
見つけて、私も英語がうまくなったなあと関心しました。（当社比）

System V Release 5 というのは、どうなったんでしたっけ？

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

Taku

未読、

2003/05/25 1:28:412003/05/25

To:

candyさんの<s7fn0hj...@xxx.kgc.co.jp>に関する投稿です。

=>これは
=><URL:http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/69921>
=>のプログラムを一日一度走らせるのがいいようです。
=>(return 0; くらいはあった方がいいかも)
=>うちは実際にこれを走らせています。
=>おかげさまで、uptime 128 days なマシン
=>(<URL:http://www.tochigi.com/ntp/>)
=>でも
=>
=>gettimeofday = 09:07:42
=> RTC = 09:07:42
=>
=>です。
やってみました。
初めてコンパイルしたので少し手間取りましたが，
何とかなりました。
BIOSの時計と電話の時報がぴったりあっています。
非常に気持ちが良いです。
有難うございました。

■
□■ Taku t...@pop.707.to

ka...@sra-tohoku.co.jp

未読、

2003/05/27 14:27:392003/05/27

To:

ko...@ie.u-ryukyu.ac.jp sed in <3988364...@insigna.ie.u-ryukyu.ac.jp>:

>> 河野真治 @ 琉球大学情報工学です。
>>
>> In article <0305172118...@ns.kobe1995.net>, k...@kobe1995.net (NAKAMURA Kazushi) writes
>> > 突然時刻がワープすると困るアプリケーションが存在しますので。
>>
>> もし、それが本当なら、ノートPCのサスペンドから復旧したときに、
>> それらは全滅ですね。

だから APMでもACPIでもサスペンド復旧時には
BIOSから「RTC読んでシステム時刻を更新しろ」と通知が来ます。

デバイスドライバ書く人しか知らなくてもいいことですが
--
kabe

Yasushi Shinjo

未読、

2003/07/28 1:37:512003/07/28

To:

新城＠筑波大学情報です。こんにちは。

SCOの裁判の話ですが、slashdot.jp の所でこんな話が出ています。

http://slashdot.jp/articles/03/07/25/1610255.shtml?topic=17
SCOがIBMの著作権を認める。
wakatono による Saturday July 26,@01:10AM

その中でも紹介されているのですが、次の Open Source
Initiative の Eric Raymond のポジション・ペーパーが面白いで
すね。

http://opensource.jp/sco/sco-vs-ibm.html

単に SCO裁判問題だけでなくて、Unix の歴史に関して書かれてい
る所なども面白いです。Unix Systems Laboratories がUC
Berkeley を訴えた裁判でも、実は、Berkeley のコードを System
V にコピーして、著作権表示を削ってコピーしていたということに
なって、逆提訴されそうになって和解したという話が面白かったで
す。

http://opensource.jp/sco/sco-vs-ibm.html#id2852926

MOCHIDA Shuji

未読、

2003/07/28 6:26:222003/07/28

To:

持田＠NETside です。

> Berkeley を訴えた裁判でも、実は、Berkeley のコードを System
> V にコピーして、著作権表示を削ってコピーしていたということに
> なって、逆提訴されそうになって和解したという話が面白かったで

具体的にどの部分がというのは未だに SCO は公には示してないらしいですが、
例として RCU, JFS, NUMA に関する部分とかいう話は出てるわけで、IBM 側から
「ウチからつっこんだのはこれだけで、SysV のコードは入ってないぞ」と
言うのは難しいことなんでしょうかね、CSRG が Net/1 や Net/2 をまとめた
みたいに。そうするとよく似た話になるんじゃないかと思うのですけども。
理由があってそれができないのかな、などとも思ってしまいます。

Yasushi Shinjo

未読、

2003/07/28 13:58:092003/07/28

To:

新城＠筑波大学情報です。こんにちは。

In article <ul81xwb...@pine.yorie.netside.co.jp>

MOCHIDA Shuji <moc...@netside.co.jp> writes:
> 具体的にどの部分がというのは未だに SCO は公には示してないらしいですが、
> 例として RCU, JFS, NUMA に関する部分とかいう話は出てるわけで、IBM 側から
> 「ウチからつっこんだのはこれだけで、SysV のコードは入ってないぞ」と
> 言うのは難しいことなんでしょうかね、

そんなことはないと思います。Open Source Initiative の Eric
Raymond のポジション・ペーパーは、「誰が contribute したのか、
それが大事で、contribute した人のものであって、System V のコー
ドベースを持っている人(SCO)ではない。」という主張ですし。

RCUって、何でしたっけ。

JFS の Journal File System ですが、RS6000 についていて、1993
年ごろ始めて見た時にはすごそうな感じがしました。当時の
System V にはそんなものは入っていません。ドキュメントの宣伝
文句はすごそうでしたが、いざ RS600 の電源をぷちっとすると、
調子悪くなったこともありました。

NUMA (non-unifrm memory access) 型のマルチプロセッサですが、
Eric Raymond の主張は、System V が動いたためしが、そもそも
ない、です。

Uniform Memory Access の共有メモリマルチプロセッサは、最近は
SMP といいますね。1985 年に出た SMP、Sequent Balnace は、
NS32032 だったけどな。その後、Symmetry というがで、これは
80386 。Balance は、使えたんだけど、Symmetry は使えなくて。
同じ大学にあるのに、頼んだらダメですって、断られてしまいまし
た。

> CSRG が Net/1 や Net/2 をまとめた
> みたいに。そうするとよく似た話になるんじゃないかと思うのですけども。
> 理由があってそれができないのかな、などとも思ってしまいます。

だから、コードの話は関係ない、ということなんでしょ。IBM と
SCO の契約の問題。コードを分離できるかどうかは関係ありません。
Raymond の話は、コードの話の所しかなくて、IBM と SCO の契約
の話は出ていません。

http://opensource.jp/sco/sco-vs-ibm.html

Linus も、最初から契約の話だと言っていたなあ。そういう意味だっ
たんだろうか。

http://www.zdnet.co.jp/enterprise/0307/09/epn35.html

Shinji KONO

未読、

2003/07/28 21:12:492003/07/28

To:

河野真治 @ 琉球大学情報工学です。

In article <YAS.03Ju...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes

> だから、コードの話は関係ない、ということなんでしょ。IBM と
> SCO の契約の問題。コードを分離できるかどうかは関係ありません。
> Raymond の話は、コードの話の所しかなくて、IBM と SCO の契約
> の話は出ていません。

たぶん、そうなんでしょうね。でも、だとしたら、文句を言われて
いるのはIBMから手にいれたLinuxだけってことなのかな?

訴訟するのは勝手だとは思うんだけど、SCOは負けたらどうなるん
でしょう? 巨額の賠償金をふっかけられるのは間違いないわけだけ
ど。なくなっちゃうんですかね。IBMに買収されちゃう? IBM が買
収しちゃうのが簡単で安上がりな気もするんだけど、きっと、もっ
と安くかたが付くと思っているんだろうな。

Tomoaki Akiyama

未読、

2003/07/28 22:15:102003/07/28

To:

y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 単に SCO裁判問題だけでなくて、Unix の歴史に関して書かれてい
> る所なども面白いです。Unix Systems Laboratories がUC
> Berkeley を訴えた裁判でも、実は、Berkeley のコードを System
> V にコピーして、著作権表示を削ってコピーしていたということに
> なって、逆提訴されそうになって和解したという話が面白かったで
> す。

　これは昔から知っていたので、「SCOがIBMにコピーされたというコードが
実はBSD由来だったら笑えるなあ」とか考えていました。

--

Tomoaki Akiyama 秋山　智朗
mailto:tom...@akiyama.nu
http://www.akiyama.nu/~tom-a/

Tomoaki Akiyama

未読、

2003/07/28 22:17:322003/07/28

To:

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
>
> 訴訟するのは勝手だとは思うんだけど、SCOは負けたらどうなるん
> でしょう? 巨額の賠償金をふっかけられるのは間違いないわけだけ
> ど。なくなっちゃうんですかね。IBMに買収されちゃう? IBM が買
> 収しちゃうのが簡単で安上がりな気もするんだけど、きっと、もっ
> と安くかたが付くと思っているんだろうな。

　IBMに買収してもらいたかったのだ、というアナリストのコメントを読んだ
記憶があります。もう先がないので、最後に一儲け、というニュアンスでした。

MOCHIDA Shuji

未読、

2003/07/28 23:19:472003/07/28

To:

持田＠NETside です。

>> 例として RCU, JFS, NUMA に関する部分とかいう話は出てるわけで、IBM 側から
>> 「ウチからつっこんだのはこれだけで、SysV のコードは入ってないぞ」と
>> 言うのは難しいことなんでしょうかね、
>
> そんなことはないと思います。Open Source Initiative の Eric
> Raymond のポジション・ペーパーは、「誰が contribute したのか、
> それが大事で、contribute した人のものであって、System V のコー
> ドベースを持っている人(SCO)ではない。」という主張ですし。

えっと、要は SysV のコードに書き足したりする形で機能が盛り込まれて
いたり、SysV（だけ）にあるものを利用する形で機能が実現されていて、
SysV のコードごとつっこんである、ということではないんでしょうかね?
要はなんらかの形で SysV のコードに依存する形になっていると。
訴えになるとしたら私はそのパターンしか思いつかないんですが..

> RCUって、何でしたっけ。

Read-Copy-Update だそうです。下記のページみつけました。

http://lse.sourceforge.net/locking/rcupdate.html

> JFS の Journal File System ですが、RS6000 についていて、1993

:

> NUMA (non-unifrm memory access) 型のマルチプロセッサですが、

:

SVR4 でマルチプロセッサー対応が云々、という話を聞いてたかと思ったら、
だーいぶしてから SVR4.2 が出て、その先に今後 SVR4.2MP でどうのとか
いう話が出て、それで SVR4.2 と SVR4.2MP は中身まったく違うというような
ことを聞いて、「なんじゃそりゃ～」と思ってた覚えがあります。
そんなんだったので、JFS や NUMA などの機能を盛り込んだのは SCO では
ないだろうとは私も思ってます。要は、依存する形で実現されているんだろうと。

で、切り離しさえすれば解決するんだけど、実はそう簡単に切り離せない、とか。

R4000 2.2

未読、

2003/07/29 14:26:522003/07/29

To:

こんばんは、立花＠鎌ヶ谷市です。

MOCHIDA Shuji <moc...@netside.co.jp> writes:

> そんなんだったので、JFS や NUMA などの機能を盛り込んだのは SCO では
> ないだろうとは私も思ってます。要は、依存する形で実現されているんだろうと。

Google で JFS を探したら、
http://www.ccur.co.jp/external/TechSup/page1.html
http://www.linux.or.jp/JF/JFdocs/Filesystems-HOWTO-9.html
というページが見つかりました。
SCO は関係ないようで。
NUMA って、IBM が買収して消えていった Sequent が最初のような気も。

--
ta...@kc5.so-net.ne.jp 立花晃＠鎌ヶ谷市

Yasushi Shinjo

未読、

2003/07/31 13:51:342003/07/31

To:

新城＠筑波大学情報です。こんにちは。

In article <3988684...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。

> > だから、コードの話は関係ない、ということなんでしょ。IBM と
> > SCO の契約の問題。コードを分離できるかどうかは関係ありません。

> たぶん、そうなんでしょうね。でも、だとしたら、文句を言われて
> いるのはIBMから手にいれたLinuxだけってことなのかな?

IBMがUnix用に開発した技術を、IBMがLinuxに転用したのが契約に
違反している、という話じゃないですか。

> 訴訟するのは勝手だとは思うんだけど、SCOは負けたらどうなるん
> でしょう? 巨額の賠償金をふっかけられるのは間違いないわけだけ
> ど。なくなっちゃうんですかね。IBMに買収されちゃう?

マイクロソフトが買う、というのはどうでしょうか。

The Open Group も、Apple が Unix の試験を通らないで MacOSX
を Unix と名乗っているのはけしからんとか訴えている暇があった
ら、Apple を見方にした方がいいと思うんだけど。

In article <bg6e9c$ni$1...@news01dh.so-net.ne.jp>

ta...@kc5.so-net.ne.jp (R4000 2.2) writes:
> SCO は関係ないようで。
> NUMA って、IBM が買収して消えていった Sequent が最初のような気も。

Sequent は、NUMA ではなくて UMA (Uniform Memory Access) で、
最近の言葉で言う所の SMP です。詳しくは
<YAS.03Ju...@kirk.is.tsukuba.ac.jp> を見て下さい。

In article <ul8el0a...@pine.yorie.netside.co.jp>

MOCHIDA Shuji <moc...@netside.co.jp> writes:
> > RCUって、何でしたっけ。
> Read-Copy-Update だそうです。下記のページみつけました。
> http://lse.sourceforge.net/locking/rcupdate.html

これも、Sequent か。ハードウェアで作っていませんでしたっけ？
Atomic Read Lock Memory とか使って。

Dynix は、一応、BSD 主でおまけで AT&T かな。シンボリック・リ
ンクがあったし。条件付きシンボリック・リンクというのがあって、
bsd と att でリンク先が変るという機能が面白かったです。

> SVR4 でマルチプロセッサー対応が云々、という話を聞いてたかと思ったら、
> だーいぶしてから SVR4.2 が出て、その先に今後 SVR4.2MP でどうのとか
> いう話が出て、それで SVR4.2 と SVR4.2MP は中身まったく違うというような
> ことを聞いて、「なんじゃそりゃ～」と思ってた覚えがあります。

System V の SMP 対応は、結局、Sun がやったんじゃないかなあ。

Linux とか FreeBSD の話を見てると、SMP 対応化はかなり難しい
くて、わかっている人が本業でガリガリやらないと、いいものはで
きないなあという印象はあります。10年前にマルチスレッドのカー
ネルを作っていたのですが、今の技術は、マルチスレッド対応だけ
見ると10年前より遅れています。完全にマルチスレッド対応にする
には、割込みレベル(slpなんとか)で相互排除しているようなコー
ドを、完全に排除しないと駄目なので、一朝一夕にはできないんだ
けどね。マイクロカーネルにはしてもしなくてもどちらでもいいん
だけれど。

Shinji KONO

未読、

2003/07/31 20:36:142003/07/31

To:

河野真治 @ 琉球大学情報工学です。

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes

> Linux とか FreeBSD の話を見てると、SMP 対応化はかなり難しい
> くて、わかっている人が本業でガリガリやらないと、いいものはで
> きないなあという印象はあります。

かなり丁寧にカーネルリソースの排他制御をしないとだめで、しか
も、リソースの使い方に応じて様々なロックを使い分けないとだめ
ですからね。でも、それだけなんじゃないかって気もしますが...
(もっとも、スケージュラ、メモリ管理周りは、まだ読んでないな)

> 10年前にマルチスレッドのカー
> ネルを作っていたのですが、今の技術は、マルチスレッド対応だけ
> 見ると10年前より遅れています。

そうかも。一方で、GUIとかはEvent driven/Call backで組まれている
わけでマルチスレッドはたくさん使われているんですよね。

> 完全にマルチスレッド対応にする
> には、割込みレベル(slpなんとか)で相互排除しているようなコー
> ドを、完全に排除しないと駄目なので、一朝一夕にはできないんだ
> けどね。マイクロカーネルにはしてもしなくてもどちらでもいいん
> だけれど。

マイクロカーネルにするとリソースへのアクセスを限定できる
ので少し設計が楽になりますね。

Linux も時代遅れな感じがしてきたので、そろそろ新しい
オープンなOSが欲しい。TRON は、ちょっといや。

MOCHIDA Shuji

未読、

2003/07/31 21:50:502003/07/31

To:

持田＠NETside です。

>> Linux とか FreeBSD の話を見てると、SMP 対応化はかなり難しい
>> くて、わかっている人が本業でガリガリやらないと、いいものはで
>> きないなあという印象はあります。
>
> かなり丁寧にカーネルリソースの排他制御をしないとだめで、しか
> も、リソースの使い方に応じて様々なロックを使い分けないとだめ
> ですからね。でも、それだけなんじゃないかって気もしますが...

デバッグ、特にデッドロックの検出方法を確立して、リソースの
ロック取得順序を決めて、それに沿って各部位を書き換えて行くような
感じの作業かと思うのですが、多人数でやるには向かない仕事ですよね。

> Linux も時代遅れな感じがしてきたので、そろそろ新しい
> オープンなOSが欲しい。TRON は、ちょっといや。

評判から行くと L4 でしょうか。

Shinji KONO

未読、

2003/07/31 22:06:052003/07/31

To:

河野真治 @ 琉球大学情報工学です。

In article <ul8n0eu...@pine.yorie.netside.co.jp>, MOCHIDA Shuji <moc...@netside.co.jp> writes

> デバッグ、特にデッドロックの検出方法を確立して、リソースの
> ロック取得順序を決めて、それに沿って各部位を書き換えて行くような
> 感じの作業かと思うのですが、多人数でやるには向かない仕事ですよね。

Processor とか Process ID とかで順序が入っているので、
その順に取得すればデッドロックはしないはずですが...

> 評判から行くと L4 でしょうか。

http://www.l4ka.org/ ですか?

Windows NTが出て Operating System は終ったとか言われたが、
最近は、Linuxが終らせたって雰囲気かなぁ。それでは、つまらなすぎ。

MOCHIDA Shuji

未読、

2003/07/31 22:16:142003/07/31

To:

持田＠NETside です。

>> 訴訟するのは勝手だとは思うんだけど、SCOは負けたらどうなるん
>> でしょう? 巨額の賠償金をふっかけられるのは間違いないわけだけ
>> ど。なくなっちゃうんですかね。IBMに買収されちゃう?

IBM は「ある一群の勢力が Linux の普及を阻止しようとしている」とか
言い出してるみたいです。IBM が負けたら SCO を批判した側の
イメージがどうなるかということも考えておいた方がよさそうです。

IBM の貢献という部分がオフィシャルになされたものなのか
個人としてなされたものなのか知らないですが、具体的に「全部で
これだけ」って示すのは簡単なはずですよね? 元になったコードも、
実際に入れたコードも、版管理してないとはとうてい思えないし。

> マイクロソフトが買う、というのはどうでしょうか。

そうなったら商用 UNIX が UNIX 離れ（SysV 離れ）して、SysV が
葬り去られるのではないでしょうか。かくして、「Unix をメシの
タネにしている連中の収入を取り上げる」という、タネンバウム教授の
予言が実現する、と。

マイクロソフトにはあんまりメリットなさそうですね。

> けどね。マイクロカーネルにはしてもしなくてもどちらでもいいん
> だけれど。

構造的にマイクロカーネルみたいになっていればモノリシックでもいい、と
いうことですよね、SunOS5 はそうなってるとだいぶ前に Sun が言ってました。

Yasushi Shinjo

未読、

2003/08/02 16:45:552003/08/02

To:

新城＠筑波大学情報です。こんにちは。

もう、Unix じゃないから、どうしますかね、Followup-To:
fj.comp.parallel にしますか。

In article <3988708...@insigna.ie.u-ryukyu.ac.jp>

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。

> そうかも。一方で、GUIとかはEvent driven/Call backで組まれている
> わけでマルチスレッドはたくさん使われているんですよね。

イベント駆動のマルチスレッドは明確に分けて考えたいという話が
あります。次の話は、面白いですよ。

J.K.Ousterhout: "Why Threads Are A Bad Idea (for most
purposes)", Invited Talk at the 1996 USENIX Technical
Conference (January 25, 1996).

http://home.pacbell.net/ouster/
http://home.pacbell.net/ouster/threads.pdf

スライドの５ページ目の図が印象的です。こんな感じ。
------------------------------------------------------------
What's Wrong With Threads?

casual all programmers wizards
>>==========================================>
<------- Visual Basic programmers -------->
<----- C programmers ------->
<-- C++ programmers -->
<-->
Threads programmers

Too hard for most programmers to use.
Even for experts, development is painful.
------------------------------------------------------------

私も、スレッドのエススパートと言ってもいいのでしょうが、最後
の最後は、これで本当にあっているのかは分からないです。これは
間違っている、というのは、だいぶ気が付くようにはなりましたが。
学生さんにレポートを出させると、とりあえず動くプログラムが返っ
ては来るんだけれど、本当にこれで大丈夫とは保証できません。な
んか怪しいけれど、ダメとも言えない。

ＯＫというのは、あるこなれたパタンがあって、それにあっている
のは、ＯＫというかんじです。マスタスレーブとかね。

それで、マルチスレッドに抗するのが、イベント駆動プログラミン
グ。スライドの9ページ目あたり。
------------------------------------------------------------
Event-Driven Programming

One execution stream: no CPU concurrency.
Register interest in events Event (callbacks).
Event loop waits for events, invokes handlers.
No preemption of event handlers.
Handlers generally short-lived.
------------------------------------------------------------

> かなり丁寧にカーネルリソースの排他制御をしないとだめで、しか
> も、リソースの使い方に応じて様々なロックを使い分けないとだめ
> ですからね。でも、それだけなんじゃないかって気もしますが...

カーネルも、スレッド意識しないで書ける所を増やしてあげればい
いんだと思います。

Shinji KONO

未読、

2003/08/03 6:01:582003/08/03

To:

河野真治 @ 琉球大学情報工学です。

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes

> イベント駆動のマルチスレッドは明確に分けて考えたいという話が
> あります。次の話は、面白いですよ。

Call back はイベント駆動のインタフェースなんだけど、実は必ず
マルチスレッドである必要があると思います。そうでないのは、さ
ぼっているだけ。

ただ、今の pthread API は、たこすぎだと思います。ちょっと低
レベル過ぎ。カーネルも同じで、実は lock API が低レベル過ぎな
ところが問題なのだと思う。このあたりのレベルを上げてやると、

> カーネルも、スレッド意識しないで書ける所を増やしてあげればい
> いんだと思います。

ということになるのだと思います。ただし!

ライブラリ呼び出し
オブジェクト指向
lock の構造の隠蔽

みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
意識しないで書けるようにすることは、実は出来ないんだと思いま
すね。

じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
チしかないと思うんだけど。新城さんもそう思うでしょ?

> もう、Unix じゃないから、どうしますかね、Followup-To:
> fj.comp.parallel にしますか。

そういうのはどうかなぁ。元のニュースグループも、尊重した
方がいいと思う。

MOCHIDA Shuji

未読、

2003/08/04 1:06:392003/08/04

To:

持田＠NETside です。

>> デバッグ、特にデッドロックの検出方法を確立して、リソースの
>> ロック取得順序を決めて、それに沿って各部位を書き換えて行くような
>> 感じの作業かと思うのですが、多人数でやるには向かない仕事ですよね。
>
> Processor とか Process ID とかで順序が入っているので、
> その順に取得すればデッドロックはしないはずですが...

カーネル内のリソース解放待を減らすにはリソースを細かい単位で
ロックするようになるので、複数の実行単位で押えるリソースの順番
間違えるとデッドロックするということのつもりなんですが..

「Processor とか Process ID とかで順序」というのはよくわからないのですが..
ひとつのリソースからみた場合ということでしょうか?
それともマイクロカーネルならロックするリソースの数も少ないし
ロックから解放までの時間も短いのでロックを多数取得する必要もない、と
いうことなんでしょうか?

MOCHIDA Shuji

未読、

2003/08/04 1:11:332003/08/04

To:

持田＠NETside です。

>> カーネルも、スレッド意識しないで書ける所を増やしてあげればい
>> いんだと思います。
>
> ということになるのだと思います。ただし!
>
> ライブラリ呼び出し
> オブジェクト指向
> lock の構造の隠蔽
>
> みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
> 意識しないで書けるようにすることは、実は出来ないんだと思いま
> すね。

なるほどです。

> じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
> チしかないと思うんだけど。新城さんもそう思うでしょ?

＃新城さんじゃないですが
なるほどです。でも、これって、うまいデバッグ方法が確立された上で、という
条件が付きますよね?

Shinji KONO

未読、

2003/08/04 1:36:422003/08/04

To:

河野真治 @ 琉球大学情報工学です。

In article <ul8ispe...@pine.yorie.netside.co.jp>, MOCHIDA Shuji <moc...@netside.co.jp> writes
> カーネル内のリソース解放待を減らすにはリソースを細かい単位で
> ロックするようになるので、複数の実行単位で押えるリソースの順番
> 間違えるとデッドロックするということのつもりなんですが..

デッドロックはロックの待ち合わせ順序にループができると起きる
ので、なんらかの順序を導入して、ロックする主体が、ロックする
複数の共有資源をその順序でロックすることにより避けることがで
きます。

データベースみたいに順序が入ってないと結構面倒です。順序をい
れようと思うとinsert/deleteに時間かかるようになったりするし。
でも、IDを入れちゃうのが最近では主流じゃないかな。

> 「Processor とか Process ID とかで順序」というのはよくわからないのですが..
> ひとつのリソースからみた場合ということでしょうか?

順序はなんでも良いです。

例えばCPUだったらCPUに順序を付ければ良いだけで、だいたい、そ
うなっているはずです。なのでSMP関連のロックでデッドロックする
のは普通はないですね。

それ以外でもカーネルの資源は順序がついているのが普通なので、
カーネル内でデッドロックってのはあまり問題にならないんじゃな
いかなぁ。

> それともマイクロカーネルならロックするリソースの数も少ないし
> ロックから解放までの時間も短いのでロックを多数取得する必要もない、と
> いうことなんでしょうか?

多数ロックするってのが、ロックとアンロックを混ぜるってことだ
と、途中でエラーしたときに極めて面倒なことになるので、普通し
ないと思う。(でもないか.... アクセスカウンタみたいなのが多い
から、そういうのはエラーしても元に戻したりしないから...)

そもそもデッドロック検出なんて重すぎてカーネル内で走らせるのは
無理ですよね。なので、デッドロックしないように作るのが普通だと
思う。

Yasushi Shinjo

未読、

2003/08/04 15:00:402003/08/04

To:

新城＠筑波大学情報です。こんにちは。

In article <3988719...@insigna.ie.u-ryukyu.ac.jp>

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。

> Call back はイベント駆動のインタフェースなんだけど、実は必ず
> マルチスレッドである必要があると思います。そうでないのは、さ
> ぼっているだけ。

並行オブジェクト指向みたいに、１オブジェクト１スレッドにして、
イベントはスレッドが好きな時に取りに行くようにすれば、どうで
しょうか。

> ということになるのだと思います。ただし!
> ライブラリ呼び出し
> オブジェクト指向
> lock の構造の隠蔽
> みたいな手法では、同期関係の抽象度のレベルを上げて、スレッド
> 意識しないで書けるようにすることは、実は出来ないんだと思いま
> すね。

シングルスレッドにして同期を「書かない」と同期の抽象化をあげ
るは、ちょっと違うかなあ。

> じゃぁ、どうするかっていうと、僕はプログラム変換的なアプロー
> チしかないと思うんだけど。新城さんもそう思うでしょ?

プログラム変換。。。ちょっとイメージがつかめません。
並列プログラムの自動生成ならイメージできるんだけど。

Yasushi Shinjo

未読、

2003/08/04 15:16:082003/08/04

To:

新城筑波大学情報です。こんにちは。

In article <ul8k79y...@pine.yorie.netside.co.jp>
MOCHIDA Shuji <moc...@netside.co.jp> writes:
> 持田＠NETside です。

> IBM は「ある一群の勢力が Linux の普及を阻止しようとしている」とか
> 言い出してるみたいです。IBM が負けたら SCO を批判した側の
> イメージがどうなるかということも考えておいた方がよさそうです。

一群の勢力の中にマイクロソフトは入っていてもいいんじゃないかと。IBM と
マイクロソフトは、.NET とか Web サービスなどで連携しているし、仲がいい
ように見えるんだけど。

著作権に関しては、次の cnet の記事が面白いですね。

------------------------------------------------------------
http://www.japan.cnet.com/news/ent/story/0,2000047623,20060273,00.htm
エンタープライズ：
L・トーバルズ：SCOの主張は「ゆすりも同然」

2003年8月1日(金) 16時51分
------------------------------------------------------------

見出しは刺激的ですが、中身の Linus のインタビューの答えが面
白いです。
----------------------------------------------------------------------
Torvaldsは、これは「集合的著作権」の問題のひとつで、作業の結果生まれた
集合体の、個々の部分に関する著作権と、全体に関する著作権とは別のものだ
と言う。

　「IBMがいくつかの部分のコード書いたとすれば、その部分のコードについ
ての著作権はIBMにある。だから、その同じIBMのコードがLinuxのなかに見ら
れるのなら、たとえそれが一行違わずそっくりだったとしても、Linuxのなか
にある以上、SCOにはそのコードについて何の権利もない。SCOが集合的著作権
を保有しているのはUNIXで、Linuxのなかのある特定のコードではないからだ」
と、Torvaldsは述べた。
----------------------------------------------------------------------

これに対してSCOの主張は、SCOとIBMの契約で、Unix の「派生物
（derivative works）」を公開することを禁じていると。

禁止していても、それが有効かという話もあるし、どこまでが派生
物で、どこからが独立したものかという話もあります。２つのシス
テムで動くものは、その時点でもう派生物とは言えないと思うんだ
けどね。

> > マイクロソフトが買う、というのはどうでしょうか。
> そうなったら商用 UNIX が UNIX 離れ（SysV 離れ）して、SysV が
> 葬り去られるのではないでしょうか。かくして、「Unix をメシの
> タネにしている連中の収入を取り上げる」という、タネンバウム教授の
> 予言が実現する、と。

どういう予言なのか、意味がよくわかりません。
Unix をメシのタネにしている連中というのは、具体的に誰ですか？

Yasushi Shinjo

未読、

2003/08/04 16:05:432003/08/04

To:

新城＠筑波大学情報です。こんにちは。
しょうがないから fj.unix らしい問題を１つ。

In article <3988721...@insigna.ie.u-ryukyu.ac.jp>

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。

> デッドロックはロックの待ち合わせ順序にループができると起きる
> ので、なんらかの順序を導入して、ロックする主体が、ロックする
> 複数の共有資源をその順序でロックすることにより避けることがで
> きます。

次のような場合、どうすればデッドロックをさけられるでしょうか。

Task1: /usr/local/share/emacs/etc と検索する。
Task2: cwd が /usr/local/share/emacs/etc で、..
/../../../.. と検索していく。

(cwd というのは、current working directory の意味。cd で変え
るもの。)

ディレクトリをロックしながら検索していくと、途中でぶつかって
デッドロックになります。（ロックしないと、検索の途中で書き換
えられたりするのでまずいわけです。）

本物のシステム(Unix, Linux, BSD)はどうしているんでしょうね。
まさか、本当にデットロックになったりしないでしょうね。

> 例えばCPUだったらCPUに順序を付ければ良いだけで、だいたい、そ
> うなっているはずです。なのでSMP関連のロックでデッドロックする
> のは普通はないですね。

最初からロックすべきものが全部わかっていたに、資源の番地でソー
トする、という方法を使ったことがあります。番号は、資源の方に
つけないと。CPU、あるいは、スレッドの番号というのは、だめてす。

> 多数ロックするってのが、ロックとアンロックを混ぜるってことだ
> と、途中でエラーしたときに極めて面倒なことになるので、普通し
> ないと思う。(でもないか.... アクセスカウンタみたいなのが多い
> から、そういうのはエラーしても元に戻したりしないから...)

ロックをしていく時に、増えていくフェーズと減っていくフェーズ
の２つのフェーズに分かれるのが、２フェーズ・ロック。その特殊
のもので、最後にバタンとロックを解除するというのが、よくあり
ます。トランザクションの実装で、アンロックまで書込みしないで、
２フェーズ・ロックを使っていると逐次化可能、という話みたい。
デットロックは、２フェーズ・ロックでも起きるんだけど、トラン
ザクションをいっしょにつかってたら、デットロックがおきたら一
度アボートして最初から矢ら直せばいいので、都合がいいというこ
とです。

Shinji KONO

未読、

2003/08/04 19:24:422003/08/04

To:

河野真治 @ 琉球大学情報工学です。

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes

> 次のような場合、どうすればデッドロックをさけられるでしょうか。
> Task1: /usr/local/share/emacs/etc と検索する。
> Task2: cwd が /usr/local/share/emacs/etc で、..
> /../../../.. と検索していく。

.. をlockする時にも、root からlockするんですね。root から
lock すれば、それで順序が付くから。ディレクトリ内のエントリ
にも順序がないとまずいけど。でも、それはlockかけすぎ。普通は
検索はlockしないで、変更するディレクトリだけにlock すると思
う。Atomic lock にするわけですね。

> 最初からロックすべきものが全部わかっていたに、資源の番地でソー
> トする、という方法を使ったことがあります。番号は、資源の方に
> つけないと。CPU、あるいは、スレッドの番号というのは、だめてす。

結果的に資源に番号がついたのと同じであれば、どっちでもだいじ
ょうぶです。

複数の資源を待たないとデッドロックしないから、システムコール
の場合は単一のlockですませるだけでも良いみたいですね。で、複
数のlockを必要とする場合は、配列に入れて配列の先頭からlockし
ていくっていう実装だったと思う。

Yasushi Shinjo

未読、

2003/08/05 4:43:022003/08/05

To:

新城＠筑波大学情報です。こんにちは。

In article <3988737...@insigna.ie.u-ryukyu.ac.jp>

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。

> > 次のような場合、どうすればデッドロックをさけられるでしょうか。
> > Task1: /usr/local/share/emacs/etc と検索する。
> > Task2: cwd が /usr/local/share/emacs/etc で、..
> > /../../../.. と検索していく。
> .. をlockする時にも、root からlockするんですね。root から
> lock すれば、それで順序が付くから。

これは、Linux の実装の話ですか。どのファイルのどのあたりか、
すぐ出てくるなら教えて下さい。

Unix のファイル・システムは、木構造といっても、厳密には、「.」
とか「..」があるので、木構造じゃなかったりするので。

> ディレクトリ内のエントリ
> にも順序がないとまずいけど。でも、それはlockかけすぎ。普通は
> 検索はlockしないで、変更するディレクトリだけにlock すると思
> う。Atomic lock にするわけですね。

検索でロックははずせなくて、やるとすると shared lock (read
lock) にするのかなあ。

検索(namei)という手続き、Unix のシステムコールでいろいろな所
から呼ばれています。opne(O_RONLY), stat(), などなど、ファイ
ル名を持つもの全部。で、システムコール単位での atomic
operation は作りたい。そうなると、今のようにするのは、わりと
自然な作りだと思います。

open() や state() を atomic にするというのは、仕様で決まって
いるので、その部分だけ見れば既に atomic operation は実現され
ているので、内部の作りは見ないことにすれば、河野さんのおっしゃ
ることは既に実現されているとも言えます。

NFS では、lookup() で名前解決する時と read()/write() する時
でタイミングがずれているので、open() できても、read() したら
ファイルがなくて失敗するということがあります。この手の不整合
を許容してもいいなら、まあ、やりようはいくらでもあるでしょうね。

> 複数の資源を待たないとデッドロックしないから、システムコール
> の場合は単一のlockですませるだけでも良いみたいですね。

こういうのは、giant lock といって、１つの方法です。Solborne
だったかなあ、SunOS (Solaris以前) を SMP 対応にしたのに、こ
の方法を使っていたと思います。Linux も、FreeBSD も、当初は
分類としてはこの方法なんでしょう。

Unix は、特に、ファイルＩ／Ｏが多いようなシステムでは、カー
ネルの中の CPU 消費が大きいので、giant lock では SMP にして
も性能が上がりません。で、ロックの単位を細かくしないといけな
いということで、Linux も FreeBSD も、頑張っていると。

NAKAMURA Kazushi

未読、

2003/08/06 1:26:492003/08/06

To:

中村和志＠神戸です。

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp>

y...@is.tsukuba.ac.jp writes:
>NFS では、lookup() で名前解決する時と read()/write() する時
>でタイミングがずれているので、open() できても、read() したら
>ファイルがなくて失敗するということがあります。この手の不整合
>を許容してもいいなら、まあ、やりようはいくらでもあるでしょうね。

NFSは状態を持たないのがセールスポイントなのですが、lockは本質的
に状態を持つことが前提というのが、NFSの難しい所。rpc.lockd,
rpc.statdとかデーモンでファイルの状態を管理するようになった
のですが、server側にしろclient側にしろ、突然マシンが落ちた時
とか、そもそもlockdで管理するのか、statdで管理するのかとか
(OSによっては片方しか実装されていないことが、特に商用OSだと
多い）、NFSだと問題は余り解決していない。

>> 複数の資源を待たないとデッドロックしないから、システムコール
>> の場合は単一のlockですませるだけでも良いみたいですね。
>
>こういうのは、giant lock といって、１つの方法です。Solborne
>だったかなあ、SunOS (Solaris以前) を SMP 対応にしたのに、こ
>の方法を使っていたと思います。Linux も、FreeBSD も、当初は
>分類としてはこの方法なんでしょう。

当初ではなく、現在も安定版はgiant lockです。開発版はgiant lock
撲滅を目標に頑張っていますけど。

>Unix は、特に、ファイルＩ／Ｏが多いようなシステムでは、カー
>ネルの中の CPU 消費が大きいので、giant lock では SMP にして
>も性能が上がりません。で、ロックの単位を細かくしないといけな
>いということで、Linux も FreeBSD も、頑張っていると。

そうです。SMPにして特に16PEとかそれ以上にしても余りトランザクション
性能が上がらなくて、WebBenchでLinuxがWindowsNTに大敗を喫して
しまいました。それでgiant lock撲滅を目指して頑張っている最中
なのですが、問題山積み状態です。問題は大きく３種類有って、

1. giant lockを潰して、小さいlockに分割して、それを活かすように
kernel内スレッドに処理を並行させられるようにしなければ意味が無い。
2. そもそもデッドロックを起こして「フリーズ」を起こしたりするのは
lockの対象となる資源が複数有って、lockを掛ける側がlockを必要と
する資源がまちまちなこと。つまり資源がA,B,C,Dと有って、lock
を掛ける側がa,b,cと有る時、a,b,cが皆A,B,C,Dを必要とするなら
A->B->C->Dの順にlockを掛ければ問題無いのだが、現実にはaはA,B,C;
bはD;cはB,C,Dだけ必要とする処理達が有って、これらプロセス｜
スレッドが他の処理達がどの資源を必要とするか感知せず、各々
好きな順にlock掛けてる状況で、デッドロックしないようにlock
を掛けるのは不可能。
3. 一番問題なのは、人。上記a,b,c共に同一人物が作っていれば、
デッドロックの危険性に気付く可能性が有るが、現実には複数
（多数）の人間が、各々好きに（寄ってたかって）開発している
現状だと、他の開発者がどの資源を必要として、どの順でlock
掛けてるかとても把握できない。

ということです。FreeBSD-currentも、KSE(kernel schedule entity),
SMP-NG(No GoodではなくNext Generation)なんかがマージされてから
各デバドラ内部で細かいlockを持つように変わってきて、結構作るのが
面倒になってきました。性能向上のためには、lock掛けてる時間を
少なくするのが、特にSMPの場合重要だとは思うのですが。
kernel内スレッドを如何にうまく分割するかを頑張るよりも、micro
kernel上で、OSサーバをマルチで走れるようにするのが、OS設計は楽
だと思うのですが、実際に労力が必要なのは結局デバイスドライバを
揃える泥臭い作業なんですよね。そんな訳でGNU(hurd)は志の高さにも
かかわらず、なかなか進まない。そもそもhurdの名の様にOSサーバが
マルチで動くようになったんでしょうか？
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.jp/>
- Be Free(BSD), or Die...

MOCHIDA Shuji

未読、

2003/08/06 2:04:082003/08/06

To:

持田＠NETside です。

>> IBM は「ある一群の勢力が Linux の普及を阻止しようとしている」とか
>> 言い出してるみたいです。IBM が負けたら SCO を批判した側の

> 一群の勢力の中にマイクロソフトは入っていてもいいんじゃないかと。IBM と

> マイクロソフトは、.NET とか Web サービスなどで連携しているし、仲がいい
> ように見えるんだけど。

つーか、当事者（IBM）が、SysV コードを入れた入れないの事実関係を
はっきりさせようという姿勢以前に、背景だの大局だのいうようなことを
コメントするというのは私は違和感ありなんです。
＃まあ IBM もデカいので、部署によっては他人事なのかも知れませんが。

> L・トーバルズ：SCOの主張は「ゆすりも同然」

これ、

> ての著作権はIBMにある。だから、その同じIBMのコードがLinuxのなかに見ら
> れるのなら、たとえそれが一行違わずそっくりだったとしても、Linuxのなか
> にある以上、SCOにはそのコードについて何の権利もない。SCOが集合的著作権
> を保有しているのはUNIXで、Linuxのなかのある特定のコードではないからだ」

ほんとにこんな話が通るんですかね? そうならなんでもコピーペースト
し放題ってことになりませんか?

＃まー、この人は昔からそうですけど。

> 物で、どこからが独立したものかという話もあります。２つのシス
> テムで動くものは、その時点でもう派生物とは言えないと思うんだ
> けどね。

そうなんですよ、だから、IBM が、問題になってる機能の関連のコードは
「別に SysV 前提じゃなくても動くし、元々独立して開発したのを AIX にも
組み込んだけだ」と言えればそれで済む話のはず。
IBM がその気になれば簡単に片付くことだと思うんですよね。

> Unix をメシのタネにしている連中というのは、具体的に誰ですか？

版権持ってる人、現在では SCO。

MOCHIDA Shuji

未読、

2003/08/06 2:23:012003/08/06

To:

持田＠NETside です。

> 2. そもそもデッドロックを起こして「フリーズ」を起こしたりするのは
> lockの対象となる資源が複数有って、lockを掛ける側がlockを必要と
> する資源がまちまちなこと。つまり資源がA,B,C,Dと有って、lock
> を掛ける側がa,b,cと有る時、a,b,cが皆A,B,C,Dを必要とするなら
> A->B->C->Dの順にlockを掛ければ問題無いのだが、現実にはaはA,B,C;
> bはD;cはB,C,Dだけ必要とする処理達が有って、これらプロセス｜
> スレッドが他の処理達がどの資源を必要とするか感知せず、各々
> 好きな順にlock掛けてる状況で、デッドロックしないようにlock
> を掛けるのは不可能。

A,B,C,D の、一部使わなくても、順序さえ守ればデッドロックはしません、
逆向きに（例えば D 押えてから B にいく）やるとデッドロックします。
で、河野さんの

> デッドロックはロックの待ち合わせ順序にループができると起きる
> ので、なんらかの順序を導入して、ロックする主体が、ロックする
> 複数の共有資源をその順序でロックすることにより避けることがで
> きます。

> でも、IDを入れちゃうのが最近では主流じゃないかな。

ということでした。

要は、資源全部に通しの順序をつけて、使いたい側で「押えたい資源一覧」を
渡すと、各資源の順序の通りにロックをかけて戻ってくる関数とか
あるといい、ということなんでしょうかね。

> kernel内スレッドを如何にうまく分割するかを頑張るよりも、micro
> kernel上で、OSサーバをマルチで走れるようにするのが、OS設計は楽
> だと思うのですが、実際に労力が必要なのは結局デバイスドライバを

マイクロカーネルにして、管理する資源を減らす代わりに、ロックは gaint で
済ませる、という考え方もありですよね。そっちの方がシンプルかも知れない。
Amoeba は個々のカーネルはシングルスレッドでしたよね。

SAITOH akinori

未読、

2003/08/06 7:02:092003/08/06

To:

大阪大学の齊藤です

MOCHIDA Shuji wrote:

> 持田＠NETside です。
> A,B,C,D の、一部使わなくても、順序さえ守ればデッドロックはしません、

> 要は、資源全部に通しの順序をつけて、使いたい側で「押えたい資源一覧」を
> 渡すと、各資源の順序の通りにロックをかけて戻ってくる関数とか
> あるといい、ということなんでしょうかね。

デッドロックはしなくなりますが、ロックしている時間が必要
最低限よりも長くなってしまいますね。

数サイクルのspinwaitでロックが成功するような資源しか
ないのならそれでかまわないでしょうが、たとえばメモリブロック
などのように得られなければblock/sleepするような資源が
混じっているとパフォーマンスがメタメタになるのでは？

なお、教科書的に言うと、こうなっています。
・ロックする順序を守れば、ひとつずつ時間をおいてロックして
　いってもデッドロックしません。
・atomicな手続きで複数の資源がロックできるなら、必要な資源を
　一気にえるようにすることでデッドロックを回避できます。
　この場合は資源の順番は気にしなくて良い。
・資源R1が得られなくてブロックする時、ロック済みの他の資源を
　一旦開放して、最初から資源ロックをretryするならば、
　デッドロックは起こりません。この場合も資源の順序は気にしな
　くてよし。

齊藤明紀　sai...@ist.osaka-u.ac.jp

Shinji KONO

未読、

2003/08/06 9:09:292003/08/06

To:

河野真治 @ 琉球大学情報工学です。

In article <bgqnb3$12d$1...@newsserv.ics.es.osaka-u.ac.jp>, SAITOH akinori <sai...@ist.osaka-u.ac.jp> writes
> デッドロックはしなくなりますが、ロックしている時間が必要
> 最低限よりも長くなってしまいますね。

kernel 内部でロックが長く待たされる状況って実は「ない」んじ
ゃないでしょうか? (giant lockみたいなのはひどいと思うけど
(動かすためには理解できます)) Linux は、いまいち、そのあたり
見通し良く作っているようには見えなかった。こまめにlock/unlock
を繰り返しているコードがたくさん入っている感じですね。
そりゃだめだろと読んでいるときに思った記憶があります。

> 数サイクルのspinwaitでロックが成功するような資源しか
> ないのならそれでかまわないでしょうが、たとえばメモリブロック
> などのように得られなければblock/sleepするような資源が
> 混じっているとパフォーマンスがメタメタになるのでは？

そりゃそうなんだけど、kernel 内でlockで待つ必要はないですよ
ね。lock の対象がswap outされていたりするなら避けようがない
かも知れないけど。

そもそもパフォーマンスを要求するようなアプリケーションはメモ
リを頻繁に取得解放なんてしちゃだめだよね。いや、もしかして、
現実は、そういうことを意識してないアプリケーションをなんとか
速く動かすのがOSの役割ってことなのか?! X Window System とか
WWW Browser、WWW Server なんて、その典型だものなぁ。

> なお、教科書的に言うと、こうなっています。
(a)
> ・ロックする順序を守れば、ひとつずつ時間をおいてロックして
> 　いってもデッドロックしません。
(b)
> ・atomicな手続きで複数の資源がロックできるなら、必要な資源を
> 　一気にえるようにすることでデッドロックを回避できます。
> 　この場合は資源の順番は気にしなくて良い。
(c)

> ・資源R1が得られなくてブロックする時、ロック済みの他の資源を
> 　一旦開放して、最初から資源ロックをretryするならば、
> 　デッドロックは起こりません。この場合も資源の順序は気にしな
> 　くてよし。

(大変良くできました(桜))

ってことは、OS全体の構成を見て、

アクセスされる資源の組みと、swapされないlockの対象

を有限個用意して、それを atomic にlockするってのが効率良さそ
うな気がします。これは、割りと、micro kernel 的な感じになり
ますよね。おそらく、「アクセスされる資源の組み」は、OS内部の
serverに対応するから。なので、究極には micro kernel の方がSMP
ではパフォーマンスが出るってことになるはずなんだが...
(しかし、そんなにうまくはいかんのだろうな)

(c) はライブロックしそう...

(昔は、こういう議論をしていると mohta 氏が解説してくれたもんだが...)

MOCHIDA Shuji

未読、

2003/08/07 1:41:382003/08/07

To:

持田＠NETside です。

>> 要は、資源全部に通しの順序をつけて、使いたい側で「押えたい資源一覧」を
>> 渡すと、各資源の順序の通りにロックをかけて戻ってくる関数とか

> デッドロックはしなくなりますが、ロックしている時間が必要
> 最低限よりも長くなってしまいますね。

えっと、でも、自分に必要な資源しかロックしないし、ロックするものに
ついては順序を守らないといけないので、余計なロックさえしなければ
いいような気がするのですが..

> 数サイクルのspinwaitでロックが成功するような資源しか
> ないのならそれでかまわないでしょうが、たとえばメモリブロック
> などのように得られなければblock/sleepするような資源が
> 混じっているとパフォーマンスがメタメタになるのでは？

そうですね.. ロックをあきらめて最初から再試行する資源を別扱い
すればいいのでしょうか。

> なお、教科書的に言うと、こうなっています。
> ・ロックする順序を守れば、ひとつずつ時間をおいてロックして
> 　いってもデッドロックしません。
> ・atomicな手続きで複数の資源がロックできるなら、必要な資源を
> 　一気にえるようにすることでデッドロックを回避できます。
> 　この場合は資源の順番は気にしなくて良い。
> ・資源R1が得られなくてブロックする時、ロック済みの他の資源を
> 　一旦開放して、最初から資源ロックをretryするならば、
> 　デッドロックは起こりません。この場合も資源の順序は気にしな
> 　くてよし。

2 番目のやつは、「atomicな手続き」というのが、すなわち giant lock て
ことにはならないのでしょうか?

3 番目のやつは、ロックの失敗によるオーバーヘッドの統計取って
性能チューニングするのが大変そう。

どれをやるにしても、後からロックの単位を変更してチューニング
できるような、抽象化したインターフェースがあるといいですよね。

「定番」とか、「この OS はうまくやってる」とか、あるんでしょうか?

Shinji KONO

未読、

2003/08/07 2:40:122003/08/07

To:

河野真治 @ 琉球大学情報工学です。

In article <ul8llu6...@pine.yorie.netside.co.jp>, MOCHIDA Shuji <moc...@netside.co.jp> writes

> 2 番目のやつは、「atomicな手続き」というのが、すなわち giant lock て
> ことにはならないのでしょうか?

giant lock は、たぶん、kernel全体でlockする対象が一つしか無い
とかいうものなんじゃないかな。

atomic lock は、複数あって良いんですが、一つのtransactionが
lock できるのは、ただ一つというものですね。

> どれをやるにしても、後からロックの単位を変更してチューニング
> できるような、抽象化したインターフェースがあるといいですよね。

その変更は「全体に及ぶ」わけで... なかなかね。

> 「定番」とか、「この OS はうまくやってる」とか、あるんでしょうか?

といわれると引き出されるのが Main Frame なんだが... 本当に
速いんだかなんだか...

Performance 的にはSolaris? RPC ならChourus?

SAITOH akinori

未読、

2003/08/10 22:39:102003/08/10

To:

MOCHIDA Shuji wrote:

> 持田＠NETside です。

> えっと、でも、自分に必要な資源しかロックしないし、ロックするものに
> ついては順序を守らないといけないので、余計なロックさえしなければ
> いいような気がするのですが..

順序を守る以上、（時間的に）余分にロックするでしょ？？？

たとえば、
1.　デバイスをロックする
2.　デバイスに対していろいろ操作する
3.　メモリエリアを取得してロックする
4.　メモリとデバイスと両方にアクセスする

という処理で、「メモリはデバイスよりも先にロックすること」
というルールがあったらどうなります？
2.の段階で使いもしない
メモリを押さえておく必要があります。これが「めもりをロック
している時間が必要最低限より長くなってしまう」という例
ですが。

齊藤明紀　sai...@ist.osaka-u.ac.jp

MOCHIDA Shuji

未読、

2003/08/11 8:24:112003/08/11

To:

持田＠NETside です。

> 順序を守る以上、（時間的に）余分にロックするでしょ？？？

あ、はい、わかります。

> たとえば、
> 1.　デバイスをロックする
:

> メモリを押さえておく必要があります。これが「めもりをロック
> している時間が必要最低限より長くなってしまう」という例
> ですが。

予想される待時間が何ケタも違うようなのをいっしょくたに順序付けては
いかん、ということですよね。

それとも、似たような待時間でも、往々にして「ムダ無く」資源を整理するのは
難しくて、順序は役に立たない、ということなのでしょうか...
その場合、対策は

>>> ・資源R1が得られなくてブロックする時、ロック済みの他の資源を
>>> 　一旦開放して、最初から資源ロックをretryするならば、

この方法しかないということになるのでしょうか?