linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karim Yaghmour <karim@opersys.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
	Roman Zippel <zippel@linux-m68k.org>,
	Tom Zanussi <zanussi@us.ibm.com>,
	Robert Wisniewski <bob@watson.ibm.com>,
	Tim Bird <tim.bird@AM.SONY.COM>
Subject: Re: [PATCH] relayfs redux for 2.6.10: lean and mean
Date: Sun, 23 Jan 2005 03:07:41 -0500	[thread overview]
Message-ID: <41F35B4D.5090409@opersys.com> (raw)
In-Reply-To: <20050121064341.GC19288@kroah.com>


Greg KH wrote:
> Are they willing to trade off the performance of LTT to get this?  I
> thought this was being touted as a "when you need to test" type of
> thing, not a "run it all the time" type of feature.

The problem is that you never know beforehand when you're going to
get that weird glitch on your server, or how much time you're going
to need to reproduce it. People who manage thousands of servers
will want to be able to fire this off at will without having to
reboot/recompile their kernel. What has to be done is make the cost
of the tracing infrastructure as minimal as possible when it is
indeed built into the kernel (of course if it's disabled it should
cost the same thing as if it wasn't there to boot: nothing.) This,
though, is a separate topic which is being addressed in other threads.
Have a look at Werner's resent postings if you're interested on the
"[RFC] instrumentation" thread.

> And a driver will never want to have both a relay channel, and a simple
> debug output at the same time?  You are now requiring them to look for
> that data in two different points in the fs.
[snip]
> So, since you are proposing that relayfs be mounted all the time, where
> do you want to mount it at?  I had to provide a "standard" location for
> debugfs for people to be happy with it, and the same issue comes up
> here.
> 
> Also, why not export your relayfs ops so that someone useing debugfs can
> create a relay channel in it, or in any other type of fs they might
> create?

Ok, there are a couple of things in there:

- First I don't object to having the relayfs ops being exported so that
they could be used in conjunction with other filesystems, in addition
to having relayfs live as an independent fs. So as in the case above, we
should be able to accomodate the device driver writer who wants to have
all his files in the same fs. However, for the first case relayfs was
built for, I think there is merit for having it live as a separate fs.
Is this a good compromise for you?

- As for where relayfs should be mounted, then this is a very good
question. We've taken to the habit of having a /relayfs. If this is
too problematic, I don't see any problem with /mnt/relayfs also. In
either case, I have to admit frankly that I'm not familiar with the
exact formal rules for introducing something like this. Of course
I'm aware of the FHS and LSB, but let me know what you think is the
best way to proceed here.

Thanks,

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

  reply	other threads:[~2005-01-23  7:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20  6:23 [PATCH] relayfs redux for 2.6.10: lean and mean Karim Yaghmour
2005-01-20 14:50 ` Greg KH
2005-01-21  1:38   ` Karim Yaghmour
2005-01-21  2:15     ` Peter Williams
2005-01-21  6:39       ` Greg KH
2005-01-21  7:27         ` Peter Williams
2005-01-21  7:46           ` Greg KH
2005-01-21  6:43     ` Greg KH
2005-01-23  8:07       ` Karim Yaghmour [this message]
2005-01-20 15:06 ` Greg KH
2005-01-20 19:51 ` Pekka Enberg
2005-02-07  3:04 ` [PATCH] relayfs crash Kingsley Cheung
2005-02-07  3:16   ` Karim Yaghmour
2005-02-07  4:42   ` Tom Zanussi
2005-02-07  4:47     ` Kingsley Cheung

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41F35B4D.5090409@opersys.com \
    --to=karim@opersys.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=bob@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@AM.SONY.COM \
    --cc=zanussi@us.ibm.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).