mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Zanussi <zanussi@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tom Zanussi <zanussi@us.ibm.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org, karim@opersys.com
Subject: Re: [PATCH 2/12] relayfs: export relayfs_create_file() with fileops param
Date: Tue, 6 Dec 2005 13:51:15 -0600	[thread overview]
Message-ID: <17301.60339.324559.226160@tut.ibm.com> (raw)
In-Reply-To: <20051206172910.GA24362@infradead.org>

Christoph Hellwig writes:
 > On Fri, Nov 11, 2005 at 01:49:05PM -0600, Tom Zanussi wrote:
 > > Christoph Hellwig writes:
 > >  > On Fri, Nov 11, 2005 at 10:47:03AM -0600, Tom Zanussi wrote:
 > >  > > This patch adds a mandatory fileops param to relayfs_create_file() and
 > >  > > exports that function so that clients can use it to create files
 > >  > > defined by their own set of file operations, in relayfs.  The purpose
 > >  > > is to allow relayfs applications to create their own set of 'control'
 > >  > > files alongside their relay files in relayfs rather than having to
 > >  > > create them in /proc or debugfs for instance.  relayfs_create_file()
 > >  > > is also used by relay_open_buf() to create the relay files for a
 > >  > > channel.  In this case, a pointer to relayfs_file_operations is passed
 > >  > > in, along with a pointer to the buffer associated with the file.
 > >  > 
 > >  > Again, NACK,  control files don't belong into relayfs.
 > >  > 
 > > 
 > > Sure, applications could just as easily create these same files in
 > > /proc, /sys, or /debug, but since relayfs is a filesystem, too, it
 > > seems to me to make sense to take advantage of that and allow them to
 > > be created alongside the relay files they're associated with, in
 > > relayfs.
 > 
 > Didn't we have that discussion before?  If we want a mix-and-match fs
 > just redo relayfs into a library of file operations for debugfs
 > (or anything else that can use file_operations for that matter)
 > 

Yes, it did come up but never went anywhere; the sticking point at the
time was the perception that debugfs is only for kernel debugging and
therefore wouldn't be configured into most kernels (whereas relayfs
presumably would), leaving non-debugging relayfs applications high and
dry if the fs part of relayfs was removed.

Other than that, it doesn't really matter whether relay files live in
relayfs or debugfs.  At one point I even had a preliminary patch that
would convert fs/relayfs/* -> fs/relay_file.c.  I could resurrect that
patch if it makes sense - from a user standpoint, the only differences
would be be that userspace would open and read relay files in
/mnt/debug instead of /mnt/relay and the kernel side would use the
debugfs directory creation functions instead of the relayfs
counterparts.

Or just leave relayfs as is, except that in that case, I do still
think these patches make sense.

Tom



  reply	other threads:[~2005-12-06 18:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11 16:44 [PATCH 0/12] relayfs: API additions and fixes Tom Zanussi
2005-11-11 16:46 ` [PATCH 1/12] relayfs: decouple buffer creation from inode creation Tom Zanussi
2005-11-11 16:47 ` [PATCH 2/12] relayfs: export relayfs_create_file() with fileops param Tom Zanussi
2005-11-11 19:37   ` Christoph Hellwig
2005-11-11 19:49     ` Tom Zanussi
2005-12-06 17:29       ` Christoph Hellwig
2005-12-06 19:51         ` Tom Zanussi [this message]
2005-11-12  2:10     ` Baruch Even
2005-11-11 16:47 ` [PATCH 3/12] relayfs: add relayfs_remove_file() Tom Zanussi
2005-11-11 16:48 ` [PATCH 4/12] relayfs: use generic_ip for private data Tom Zanussi
2005-11-11 16:49 ` [PATCH 5/12] relayfs: remove unused alloc/destroy_inode() Tom Zanussi
2005-11-11 16:50 ` [PATCH 6/12] relayfs: add Documention for non-relay files Tom Zanussi
2005-11-11 16:51 ` [PATCH 7/12] relayfs: add support for relay files in other filesystems Tom Zanussi
2005-11-11 16:51 ` [PATCH 8/12] relayfs: add Documentation on " Tom Zanussi
2005-11-11 16:52 ` [PATCH 9/12] relayfs: add support for global relay buffers Tom Zanussi
2005-11-11 16:52 ` [PATCH 10/12] relayfs: add Documentation on " Tom Zanussi
2005-11-11 16:53 ` [PATCH 11/12] relayfs: cleanup, change relayfs_file_* to relay_file_* Tom Zanussi
2005-11-11 16:54 ` [PATCH 12/12] relayfs: Documentation cleanup, remove obsolete info Tom Zanussi

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=17301.60339.324559.226160@tut.ibm.com \
    --to=zanussi@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®