public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: sekharan@us.ibm.com
Cc: greg@kroah.com, menage@google.com,
	ckrm-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	matthltc@us.ibm.com
Subject: Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs
Date: Mon, 16 Oct 2006 19:59:52 -0700	[thread overview]
Message-ID: <20061016195952.415f4939.pj@sgi.com> (raw)
In-Reply-To: <1161037741.5057.2.camel@linuxchandra>

> Quick look at the seq_file interfaces shows there is no such capability.

Perhaps a seq file size limit could be added.  Not sure if that's
a good idea or not ...

Ah - cap the count + ppos the user passed in to configfs_read_file,
before passing these values to flush_read_buffer().

If the user asks for more than is allowed, give them only what they are
allowed, by passing a smaller count to flush_read_buffer().  If they
start at a position past what's allowed, force a huge ppos and let them
see the resulting EOF.  Disclaimer - I too am no seq_file expert ;).

This should be just a few more lines in configfs_read_file() on
top of your current patches adapting it to seq_file.

Granted - it is not going in directly in one step to the objective you
seek, that being a configfs suitable for displaying a long vector of
process id's, so that Resource Groups can make use of it (and maybe
someday cpusets, too.)

But it gains the code reduction and reuse benefits of your patch
set, and gets this conversation unwedged, so we can go on to discuss
whether or not it would be a good idea go add a suitable vector
interface to seq_file, without threatening the excellent improvements
that sysfs/configfs have made over the old /proc style mess.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2006-10-17  3:00 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-10 18:20 [PATCH 0/5] Allow more than PAGESIZE data read in configfs Chandra Seetharaman
2006-10-10 18:20 ` [PATCH 1/5] Fix a module count leak Chandra Seetharaman
2006-10-10 22:17   ` Joel Becker
2006-10-10 18:20 ` [PATCH 2/5] Use seq_file for read side of operations Chandra Seetharaman
2006-10-11  9:12   ` Joel Becker
2006-10-10 18:21 ` [PATCH 3/5] Change configfs_example.c to use the new interface Chandra Seetharaman
2006-10-10 18:21 ` [PATCH 4/5] Change Documentation to reflect " Chandra Seetharaman
2006-10-10 18:21 ` [PATCH 5/5] Change the existing code to use " Chandra Seetharaman
2006-10-10 20:35 ` [PATCH 0/5] Allow more than PAGESIZE data read in configfs Joel Becker
2006-10-10 21:31   ` [ckrm-tech] " Paul Menage
2006-10-10 21:58     ` Joel Becker
2006-10-10 23:13       ` Chandra Seetharaman
2006-10-11  0:15         ` Joel Becker
2006-10-11  0:49       ` Matt Helsley
2006-10-11  1:28         ` Joel Becker
2006-10-11 22:39           ` Greg KH
2006-10-11 23:26             ` Chandra Seetharaman
2006-10-12  4:17               ` Paul Jackson
2006-10-12 23:51               ` Greg KH
2006-10-13  0:16                 ` Paul Jackson
2006-10-13 23:38                   ` Matt Helsley
2006-10-13 23:40                 ` Matt Helsley
2006-10-13 23:47                   ` Paul Menage
2006-10-14  6:17                   ` Greg KH
2006-10-14 23:14                     ` Matt Helsley
2006-10-16 19:10                 ` Chandra Seetharaman
2006-10-16 20:32                   ` Paul Jackson
2006-10-16 22:29                     ` Chandra Seetharaman
2006-10-17  2:59                       ` Paul Jackson [this message]
2006-10-12  2:17             ` Matt Helsley
2006-10-12 23:54               ` Greg KH
2006-10-13  3:22                 ` Matt Helsley
     [not found]           ` <20061011220619.GB7911@ca-server1.us.oracle.com>
     [not found]             ` <1160619516.18766.209.camel@localhost.localdomain>
2006-10-12  7:08               ` Joel Becker
2006-10-12 21:44                 ` Paul Jackson
2006-10-12 22:51                   ` Joel Becker
2006-10-13  0:01                     ` Paul Jackson
2006-10-14  4:40                       ` Greg KH
2006-10-13 23:37                 ` Matt Helsley
2006-10-14  0:09                   ` Joel Becker
2006-10-15  1:06                     ` Matt Helsley
2006-10-15 19:07                     ` Paul Jackson
2006-10-16 19:33                     ` Chandra Seetharaman
2006-10-16 23:07                       ` Joel Becker
2006-10-11 20:19   ` Andrew Morton
2006-10-11 21:41     ` Joel Becker
2006-10-11 22:18     ` Joel Becker
2006-10-11 22:48       ` Andrew Morton
2006-10-11 23:27         ` Chandra Seetharaman
2006-10-14  8:01           ` Greg KH
2006-10-14 19:43             ` Andrew Morton
2006-10-14 20:10               ` Joel Becker
2006-10-16 19:24                 ` Chandra Seetharaman
2006-10-16 23:09                   ` Joel Becker
2006-10-18  0:55                     ` Chandra Seetharaman
2006-10-19 18:42                       ` Joel Becker
2006-10-16 19:16             ` Chandra Seetharaman

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=20061016195952.415f4939.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=menage@google.com \
    --cc=sekharan@us.ibm.com \
    /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