All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	leemgs1@gmail.com, linux-kernel <linux-kernel@vger.kernel.org>,
	mathieu.desnoyers@polymtl.ca,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH 1/5] debugfs - Fix mount directory of debugfs by default in events.txt
Date: Mon, 07 Sep 2009 18:27:00 -0400	[thread overview]
Message-ID: <1252362420.2964.53.camel@localhost.localdomain> (raw)
In-Reply-To: <20090907213047.GA28651@kroah.com>

On Mon, 2009-09-07 at 14:30 -0700, Greg KH wrote:

> > 
> > From what people tell me it wasn't a clear consensus.
> 
> Specifics please.

Well I still avoid it. I've been broken into telling people publicly to
mount it in /sys/kernel/debug, but I've never done it myself.

> 
> > > So what is the problem?
> > 
> > Its not related to sysfs in any way I can discover,
> 
> So, other filesystems are mounted in sysfs, and in /proc for many years.
> 
> > its not consistent with most of the other virtual fs',
> 
> What do you mean by this?
> 
> > and its way too much typing.
> 
> tab completion is your friend, as is environment variables.  Don't
> choose stuff just because you are lazy :)

/sy <tab> k <tab> d <tab>

   or

/deb <tab>

I like the second one much better.

> 
> > we don't mount /dev, /proc, /sys in weird places either, so why should
> > we mount /debug in a cumbersome location.
> 
> Because it is a _kernel_ debug thing, not a system-level debug thing.
> What would userspace developers think about /debug ?  Why would they
> care about such a thing?
> 
> As much as we tend to ignore it, kernel developers are not the primary,
> or only, users of Linux :)

Actually this is a very good point. I think that the tracing system has
matured beyond a "debug" level and is being enabled on production
systems. Both fedora and debian are now shipping kernels with it
enabled. Perhaps we should create another pseudo fs that can be like
debugfs but for stable ABIs. A new interface could start out in debugfs,
but when it has reached a stable interface, then it could be moved to
another location to signal this.

/proc has been criticized for the pollution of non process related
information. This happened because there was no place else to place it.
Then came /sys which was suppose to take over this, but IMHO, it is too
over-engineered and too complex to use (I still stumble over kobjects).
I found that debugfs was a nice and simple interface to use. What about
creating a new fs that works like debugfs but is for stable interfaces
and can be mounted at root?

   /kernel?


-- Steve



  reply	other threads:[~2009-09-07 22:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07 12:37 [PATCH 1/5] debugfs - Fix mount directory of debugfs by default in events.txt GeunSik Lim
2009-09-07 12:48 ` Peter Zijlstra
2009-09-07 18:55   ` Greg KH
2009-09-07 19:15     ` Peter Zijlstra
2009-09-07 21:30       ` Greg KH
2009-09-07 22:27         ` Steven Rostedt [this message]
2009-09-08  1:27           ` GeunSik Lim

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=1252362420.2964.53.camel@localhost.localdomain \
    --to=srostedt@redhat.com \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=leemgs1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.