Re: [PATCH 2/12] relayfs: export relayfs_create_file() with fileops param

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux