From sugita ＠ sdl.hitachi.co.jp Thu Oct 3 18:46:01 2002 From: sugita ＠ sdl.hitachi.co.jp (Yumiko Sugita) Date: Thu, 03 Oct 2002 18:46:01 +0900 Subject: [Lkst-develop] Re: Release of LKST 1.3 In-Reply-To: <3D947DC3.EEC6C0A6@opersys.com> References: <5.0.2.6.2.20020918210036.05287a40@sdl99c> <5.0.2.6.2.20020918210036.05287a40@sdl99c> <5.0.2.6.2.20020926182552.0506a898@sdl99c> Message-ID: <5.0.2.6.2.20021003183537.06a8ad90@sdl99c> Hello, Mr. Karim I'm Yumiko Sugita, a member of LKST developers. I read your mail. Thank you for your advices. The features for SMP are one of our important aims, so we, LKST developpers, developed them. We welcome IBM's work on them. We think callback feature is useful for kernel developers. Are there any problems?　Are you going to remove callbacks from LTT? Is the main reason security? If you have some cases of security problems about callbacks, please teach them and give some advice to us. After future, we'll join community actively. We'll use LTT and want to concern LTT, so we'll join the discussion of you and other LTT developers about Linux RAS. We hope to co-operate you and other developers about Linux RAS. Best regards, *〜*〜*〜*〜*〜 Yumiko Sugita Hitachi, Ltd., Systems Development Laboratory Email : sugita ＠ sdl.hitachi.co.jp 　　　　　 〜*〜*〜*〜*〜* At 11:48 02/09/27 -0400, Karim Yaghmour wrote: >Just a couple of general observations here. > >Yumiko Sugita wrote: > > Consequently, LKST, which is oriented to enterprise systems, > > has the following features different from those of LTT. > > # These LKST features are also being enhanced at this time. > > > > (1) Little overhead and good scalability when tracing on a large-scale > > SMP system > > * To make lock mechanism overhead as little as possible, we > > designed that the buffers are not shared among CPUs. > >I was wondering whether you followed the recent discussion about LTT on the >LKML? Clearly this is not a problem for LTT since we don't use any form >of locking whatsoever anymore. IBM's work on the lockless scheme has >solved this problem and their current work on the per-CPU buffering solves >the rest of the issue. > > > (2) Easy to extend/expand the function (User-based extendibility) > > * Without recompiling kernel, user can change/add/modify the kind > > of events and information to be recorded at anytime. > >Ditto with LTT. > > > For example, LKST usually traces very few events for the purpose > > of good performance. Once the kernel get into the particular status > > that user specified, LKST will trace and record more detail information. > >This implies callbacks, which do exist in LTT and which Ingo Molnar explicitly >asked us to remove. > > > (3) Preservation of trace information > > * Recovery of trace information collected at the time of a system crash > > in connection with LKCD. > >Connection with LKCD is really not a problem, but this points to the main >purpose of the tool, which in the case of LKCD is kernel debugging. LTT isn't >aimed as a kernel debugger, so although LKCD is on our to-do list, it's >certainly not our priority. > >As for handling multiple output streams (which LKCD can be one of them), we >already have very detailed plans on how LTT is going to integrate this (as I've >mentioned a number of times before on this list). However, before we go down >this road we need to make sure that the core tracing functionality is >lightweight and fits the general requirements set for kernel code. Once this >core lighweight functionality is there, we can build a rich and solid feature >set around it. > > > * Saving of specific event information during tracing. > > For example, switching to another buffer after the occurrence of > > a specific event enables the information on that event to be left > > in the previous buffer. > >Again, callbacks and triggers. A while back, I had written a state machine >engine for LTT. Basically, you could provide it with an event-driven state >machine and it would callback your functions depending on the sequence of >events. All of this obviously implies callbacks, which, as I said earlier, >we've been explicitly asked to remove. > > > (4) Collection of even more kernel event information > > * Information on more than 50 kernel events can be collected for > > kernel debugging. > >Well, I think this is where LTT and LKST cannot be compared. If LKST is >a kernel debugging tool, as it has always been advertised, then any comparison >of LKST should be made with the other tracing tools which are used for >kernel debugging, such as the ones mentioned by Ingo and Andi earlier on >this list. > >LTT was built from the ground up to help users understand the dynamic >behavior of the system. As such, it cannot be compared to any kernel >debugging tool since it isn't one. > > > The demand for RAS functions in Linux should grow in the years to come. > > It is our hope that LKST becomes one means of implementing such functions. > >There was a RAS BoF at the OLS this year where tracing was intensively >discussed. >All the attendees agreed to unify their efforts around LTT. At this meeting, >Richard Moore of IBM presented a tracing to-do list >(http://opersys.com/LTT/ltt-to-do-list.txt) which we are using a basic >check list for our ongoing work. Instead of implementing yet another tracing >system, I think that the LKST team would benefit much from contributing to >LTT, which has already a proven track record and has been adopted by the >community as much as the industry. > >Karim > >=================================================== > Karim Yaghmour > karim ＠ opersys.com > Embedded and Real-Time Linux Expert >=================================================== >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo ＠ vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ From hiramatu ＠ sdl.hitachi.co.jp Tue Oct 8 17:08:49 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 08 Oct 2002 17:08:49 +0900 Subject: [Lkst-develop] [PATCH]lkstlogdリソース解放 Message-ID: <3DA29291.8030903@sdl.hitachi.co.jp> 各位 日立の平松です。 LKST1.3のlkstlogdに対するパッチを作成しました。 1) lkstlogdが実行に失敗して終了するときに、確実にマスクセットやバッファ、 pidファイルを解放するようにします。 2) 停止時にLKSTのモジュールがアンロードされないようにロックを行います。 3) バッファをスキップするときに、エラーと表示されていたのを、スキップを行ったことを 表示するように修正しました。 4) lkstlogd用のマスクセットを作るときに、ロック関連のイベントはとらないように 修正しました。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 -------------- next part -------------- 文字コード指定の無い添付文書を保管しました... 名前: lkst-1.3-logd_free_resources.patch URL: http://lists.sourceforge.jp/mailman/archives/lkst-develop/attachments/20021008/c647d035/attachment.txt From karim ＠ opersys.com Thu Oct 10 03:05:51 2002 From: karim ＠ opersys.com (Karim Yaghmour) Date: Wed, 09 Oct 2002 14:05:51 -0400 Subject: [Lkst-develop] Re: Release of LKST 1.3 References: <5.0.2.6.2.20020918210036.05287a40@sdl99c> <5.0.2.6.2.20020918210036.05287a40@sdl99c> <5.0.2.6.2.20020926182552.0506a898@sdl99c> <5.0.2.6.2.20021003183537.06a8ad90@sdl99c> Message-ID: <3DA46FFF.2A0347C5@opersys.com> ... sorry for the delay, I'm very busy lately ... Yumiko Sugita wrote: > We think callback feature is useful for kernel developers. > Are there any problems?$B!!(BAre you going to remove callbacks > from LTT? Is the main reason security? If you have some > cases of security problems about callbacks, please teach > them and give some advice to us. The issue of callbacks was covered by one of Ingo's comments about LTT. Here's the excerpt from his mail: > okay. The thing is that generic callbacks and data hooks in the task > structure are an invitation for various types of abuses - security and GPL > type abuses. People do get very nervous when seeing such stuff - eg. read > back Christoph Hellwig's comment from a few weeks ago. It's a red flag for > many people. Provide a clean and concentrated set of APIs, no callbacks, > no unnecessery hooks. I can see the technical reasons why you have added > it - it's in theory an extensible interface, but generally we tend to add > such stuff when it's needed - if it's needed at all. (You can get the complete copy from: http://marc.theaimsgroup.com/?l=linux-kernel&m=103276662708853&w=2) If you would like to provide callbacks for _kernel developers_ then these callbacks should live as an outside patch, as with any other facility that is useful to kernel development only. If there is a legitimate need for such hooks later on, then we can add them when needed, as Ingo suggested. None of it is really complicated. These callbacks would also have to be exported as GPL-only, in order to avoid any sort of abuse. The main issue we are concentrating on at this time, however, is to make sure that the core infrastructure is lightweight and solid. Any additional features will be added on top of this core infrastructure. > After future, we'll join community actively. We'll use LTT > and want to concern LTT, so we'll join the discussion of you > and other LTT developers about Linux RAS. > We hope to co-operate you and other developers about > Linux RAS. We certainly welcome any contribution and will be happy to help you integrate your features into a common tracing infrastructure. Feel free to join in the discussion around the LTT development mailing list (See the project's web site for details on how to subscribe). Best regards, Karim =================================================== Karim Yaghmour karim ＠ opersys.com Embedded and Real-Time Linux Expert =================================================== From hiramatu ＠ sdl.hitachi.co.jp Tue Oct 15 09:23:07 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 15 Oct 2002 09:23:07 +0900 Subject: [Lkst-develop] lkst 1.3 例外ハンドラの修正 Message-ID: <3DAB5FEB.9080806@sdl.hitachi.co.jp> 日立の平松です。 lkst v1.3までのバージョンで、例外ハンドラ(LKST_ETYPE_EXCEPTION_ENTRY)において lkst_evhandlerprim_entry_log_l2()関数を呼び出す処理をするハンドラを用意した 場合に、一部のコンパイラ(※)を使ってコンパイルを行ったハンドラを使用すると、 ハングアップやリブートが発生してしまう不具合がありました。 ※手元ではRedHat7.1/RedHat7.3のgcc2.96において確認されています。 これは例外ハンドラ呼び出しの後で、関数呼び出しに使用したスタックから ediレジスタ内容を復活させようとするためです。 このため拡張モジュールを使わない通常運用においては問題はありません。 この不具合に対処するための修正パッチを添付します。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 -------------- next part -------------- 文字コード指定の無い添付文書を保管しました... 名前: lkst-1.3-exception_entry_no_pop_edi.patch URL: http://lists.sourceforge.jp/mailman/archives/lkst-develop/attachments/20021015/de6af5f3/attachment.txt From yasuma ＠ miraclelinux.com Fri Oct 18 19:12:34 2002 From: yasuma ＠ miraclelinux.com (Yasuma Takeda) Date: Fri, 18 Oct 2002 19:12:34 +0900 Subject: [Lkst-develop] LKST V1.3のデバッグ文 Message-ID: <20021018191234.2aaeea3c.yasuma@miraclelinux.com> ミラクル・リナックスの武田です。 LKST V1.3ですが、以下のデバッグ文は消し忘れでしょうか? lkst_kernel.c lkst_dummy_vmalloc() + /* get pages dirty... */ + for ( i = 0; i < size ; i+= PAGE_SIZE) { + buf[i] = i+1; + } + vfree(buf); + /*DEBUG*/ printk("buf=%#x,size=%#x",buf,size); <--- ここ + lkst.available_memory_size = size; + (char *) lkst.limit_addr = (char *) buf + size; -- ------------------------------ 武田 保真 (Yasuma Takeda) E-mail:yasuma ＠ miraclelinux.com http://www.miraclelinux.com ------------------------------ From hiramatu ＠ sdl.hitachi.co.jp Mon Oct 21 09:15:19 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Mon, 21 Oct 2002 09:15:19 +0900 Subject: [Lkst-develop] LKST V1.3のデバッグ文 References: <20021018191234.2aaeea3c.yasuma@miraclelinux.com> Message-ID: <3DB34717.4040709@sdl.hitachi.co.jp> 日立の平松です。 Yasuma Takeda wrote: > ミラクル・リナックスの武田です。 > > LKST V1.3ですが、以下のデバッグ文は消し忘れでしょうか? はい、size情報等はこの後の部分で表示されるので、 このprintkは不要ですね。 #元々はvmallocした後に表示していたのですが、fixしたときに #消し忘れてしまったようです。 情報ありがとうございます。 これからもよろしくお願いします。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346