From: Karim Yaghmour <email@example.com>
To: Yumiko Sugita <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
email@example.com, LTT-Dev <firstname.lastname@example.org>
Subject: Re: [Lkst-develop] Re: Release of LKST 1.3
Date: Wed, 09 Oct 2002 14:05:51 -0400 [thread overview]
Message-ID: <3DA46FFF.2A0347C5@opersys.com> (raw)
... 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:
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
Embedded and Real-Time Linux Expert
next prev parent reply other threads:[~2002-10-09 17:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-18 12:20 Release of LKST 1.3 Yumiko Sugita
2002-09-19 5:58 ` Robert Schwebel
2002-09-26 12:36 ` [Lkst-develop] " Yumiko Sugita
2002-09-27 15:48 ` Karim Yaghmour
2002-10-03 9:46 ` Yumiko Sugita
2002-10-09 18:05 ` Karim Yaghmour [this message]
2002-09-19 8:18 ` Vamsi Krishna S.
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).