ons.
Although this is not a long piece of code it is unneccessary boilerplate.
seq_open() remains in place and its behaviour remains unchanged so no
existing code should be broken by this patch.
Signed-off-by: Ian Molton
Signed-off-by: Rob Jones
---
Documentation/filesystems/seq_file.txt |
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in fscache_objlist_open().
Signed-off-by: Rob Jones
---
Note that sparse generates a warning on this file but it is outside the
remit of this patch.
Note 2, it looks to me like the sparse warning may be a false
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in kallsyms_open().
Signed-off-by: Rob Jones
---
kernel/kallsyms.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index cb0cf37..606664d 100644
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in xt_match_open() and xt_target_open().
Signed-off-by: Rob Jones
---
This patch uses an existing variant of seq_open() to reduce the kernel code
size.
The only significant variation from the pre-existing code is the
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in xt_match_open() and xt_target_open().
Signed-off-by: Rob Jones
---
This patch uses an existing variant of seq_open() to reduce the kernel code
size.
The only significant variation from the pre-existing code is the
On 23/09/14 22:40, Pablo Neira Ayuso wrote:
On Tue, Sep 23, 2014 at 06:46:27PM +0100, Ben Hutchings wrote:
On Tue, 2014-09-23 at 18:05 +0100, Rob Jones wrote:
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in xt_match_open() and xt_target_open().
Signed-off-by
patch is accepted, the instances of boilerplate code can be
addressed.
The documentation of seq_open() and its variants has been re-worked to try
to guide users towards the most appropriate variant for their application.
Rob Jones (2):
fs/seq_file: Create new function seq_open_init
Add documentation for new function and restructure existing text
in the same area.
Signed-off-by: Rob Jones
---
Documentation/filesystems/seq_file.txt | 58 +---
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/Documentation/filesystems/seq_file.txt
e new function.
Signed-off-by: Rob Jones
---
fs/seq_file.c| 34 ++
include/linux/seq_file.h |1 +
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index dc2dfec..4be3aa8 100644
--- a/fs/seq_file.c
+++
On 24/09/14 19:06, Kees Cook wrote:
On Wed, Sep 24, 2014 at 4:15 AM, Rob Jones wrote:
Series resubmitted due to a typo in an email address.
This patch series implements and documents a new interface function for
seq_file.
The existing set of open functions: seq_open(), seq_open_private
On 24/09/14 22:39, Andrew Morton wrote:
On Wed, 24 Sep 2014 12:15:55 +0100 Rob Jones wrote:
Add a new function to help reduce boilerplate code.
This is a wrapper function for seq_open() that will simplify the code in a
significant number of cases where seq_open() is currently called.
It
On 25/09/14 17:09, Kees Cook wrote:
On Thu, Sep 25, 2014 at 1:57 AM, Rob Jones wrote:
On 24/09/14 19:06, Kees Cook wrote:
On Wed, Sep 24, 2014 at 4:15 AM, Rob Jones
wrote:
Series resubmitted due to a typo in an email address.
This patch series implements and documents a new interface
On 25/09/14 15:49, Randy Dunlap wrote:
On 09/25/14 02:10, Rob Jones wrote:
On 24/09/14 22:39, Andrew Morton wrote:
On Wed, 24 Sep 2014 12:15:55 +0100 Rob Jones wrote:
Add a new function to help reduce boilerplate code.
This is a wrapper function for seq_open() that will simplify the
On 25/09/14 18:50, Andrew Morton wrote:
On Thu, 25 Sep 2014 10:10:05 +0100 Rob Jones wrote:
A global exported-to-modules interface should be documented, please.
Especially when it has a void* argument. seq_file.c is patchy - some
of it is documented, some of it uses the read-programmers
On 01/09/14 16:36, Al Viro wrote:
On Mon, Sep 01, 2014 at 02:17:08PM +0100, Rob Jones wrote:
void *__seq_open_private(struct file *f, const struct seq_operations *ops,
- int psize)
+ size_t psize)
It is a horrible limitation to impose, indeed. Why, a lousy
2
Reduce boilerplate code by using __seq_open_private() instead of seq_open().
Signed-off-by: Rob Jones
---
fs/proc/task_mmu.c | 42 --
1 file changed, 16 insertions(+), 26 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 442177b
Reduce boilerplate code by using __seq_open_private() instead of seq_open().
Signed-off-by: Rob Jones
---
fs/proc/task_nommu.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index 678455d..b141050 100644
Use __seq_open_private() to reduce boilerplate code in proc.
This function has been around, undocumented, for years. It can simplify
the set up code for seq file operations.
Signed-off-by: Rob Jones
Rob Jones (2):
fs: proc: use __seq_open_private()
fs: proc: use __seq_open_private()
fs
On 12/09/14 15:16, Richard Weinberger wrote:
On Thu, Sep 11, 2014 at 6:25 PM, Rob Jones wrote:
On 01/09/14 16:36, Al Viro wrote:
On Mon, Sep 01, 2014 at 02:17:08PM +0100, Rob Jones wrote:
void *__seq_open_private(struct file *f, const struct seq_operations
*ops,
- int
I submitted the patch below on 17th September but have had no feedback.
It seems to me a worthwhile change (well, I wouldn't have written it
otherwise) but does anybody else have any comments on it?
On 17/09/14 09:56, Rob Jones wrote:
Reduce boilerplate code by using __seq_open_pr
On 12/09/14 22:54, Andrew Morton wrote:
On Fri, 12 Sep 2014 15:09:37 +0100 Rob Jones wrote:
Reduce boilerplate code by using __seq_open_private() instead of seq_open().
http://ozlabs.org/~akpm/mmots/broken-out/fs-proc-task_nommuc-change-maps_open-to-use-__seq_open_private.patch
already did
On 12/09/14 22:50, Andrew Morton wrote:
On Fri, 12 Sep 2014 15:09:36 +0100 Rob Jones wrote:
fs: proc: use __seq_open_private()
fs: proc: use __seq_open_private()
See the problem? We have two different patches, both named the same.
Always another gotcha! :-)
Seriously, does it say
On 12/09/14 22:54, Andrew Morton wrote:
On Fri, 12 Sep 2014 15:09:37 +0100 Rob Jones wrote:
Reduce boilerplate code by using __seq_open_private() instead of seq_open().
http://ozlabs.org/~akpm/mmots/broken-out/fs-proc-task_nommuc-change-maps_open-to-use-__seq_open_private.patch
already
On 18/06/14 14:05, Heiko Stübner wrote:
Am Dienstag, 10. Juni 2014, 15:41:47 schrieb Rob Jones:
Add function devm_kmemdup().
Rationalise with devm_kstrdup() to avoid code duplication.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/base/devres.c | 42
On 18/06/14 14:24, Heiko Stübner wrote:
Am Dienstag, 10. Juni 2014, 15:41:46 schrieb Rob Jones:
Add functions devm_gpio_request_array() and devm_gpio_free_array()
which are exactly analogous to the equivalent non-managed device
functions gpio_request_array() and gpio_free_array(), which can be
.
No indication is provided as to which particular request failed.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/gpio/devres.c | 57 +
include/linux/gpio.h |4
2 files changed, 61 insertions(+)
diff --git a/drivers/gpio
Add function devm_kmemdup().
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/base/devres.c | 27 ++-
include/linux/device.h |2 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index
Avoid code duplication by using devm_kmemdup() to copy data instead
of having a separate loop within devm_kstrdup().
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/base/devres.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/base/devres.c b
Use managed resource functions for all resource allocations in
gpio_regulator_probe().
Remove gpio_regulator_remove() as it is now redundant.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/regulator/gpio-regulator.c | 70
1 file changed, 23
Rob Jones # This line is ignored.
From: Rob Jones
Subject:
In-Reply-To:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
On 19/06/14 18:57, Mark Brown wrote:
On Thu, Jun 19, 2014 at 04:46:01PM +0100, Rob Jones wrote:
Add new managed resource functions as needed to achieve this.
Amend the following functions:
You appear to have omitted the actual patch, I'm quoting the entire
mail here. Pleas
On 19/06/14 16:59, Joe Perches wrote:
On Thu, 2014-06-19 at 16:46 +0100, Rob Jones wrote:
Avoid code duplication by using devm_kmemdup() to copy data instead
of having a separate loop within devm_kstrdup().
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
[]
diff --git a/drivers/base
On 24/07/14 16:59, Greg KH wrote:
On Thu, Jul 24, 2014 at 04:18:01PM +0100, Rob Jones wrote:
Reviewed-by: Ian Molton
Suggested-by: Ben Dooks
Signed-off-by: Rob Jones
---
Documentation/driver-model/devres-debugfs.txt | 140 +
drivers/base/Kconfig | 18
On 11/07/14 01:35, Javier Martinez Canillas wrote:
Hello Rob,
On Thu, Jul 10, 2014 at 1:01 PM, Rob Jones wrote:
I will certainly consider it. I'm in the middle of something else right
now but I should be available in a day or two and I'll have a look.
I'm working on
Add function devm_kmemdup() which is exactly analogous to the
non-managed device function kmemdup().
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/base/devres.c | 25 +
include/linux/device.h |2 ++
2 files changed, 27 insertions(+)
diff --git a
Extend the use of managed resource functions in regulator by replacing
all calls to unmanaged resource allocation functions in
gpio_regulator_probe() with their managed equivalent.
Add a new function, devm_kmemdup(), to drivers/base/devres.c to support this.
Rob Jones (3):
base: Add block copy
Use managed resource functions for all resource allocations in
gpio_regulator_probe().
Remove gpio_regulator_remove() as it is now redundant.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/regulator/gpio-regulator.c | 70
1 file changed, 23
Add functions devm_gpio_request_array() and devm_gpio_free_array()
which are exactly analogous to the equivalent non-managed device
functions gpio_request_array() and gpio_free_array(), which can be
found in the module gpiolib.c.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers
device *dev, unsigned gpio,
unsigned long flags, const char *label);
+int devm_gpio_request_array(struct device *dev, const struct gpio *array,
+ size_t num);
void devm_gpio_free(struct device *dev, unsigned int gpio);
#else /* ! CONFIG_GPIOLIB */
On 09/07/14 12:52, Julia Lawall wrote:
On Wed, 9 Jul 2014, Rob Jones wrote:
Please note that I submitted a patch on 02/07/14 to create this
function which was acked by Linus Walleij on 05/07/14.
Great minds think alike, and all that.
However, I think that the version I submitted better
On 10/07/14 10:21, Linus Walleij wrote:
On Wed, Jul 9, 2014 at 1:18 PM, Rob Jones wrote:
Please note that I submitted a patch on 02/07/14 to create this
function which was acked by Linus Walleij on 05/07/14.
Great minds think alike, and all that.
My mind certainly isn't any
Reviewed-by: Ian Molton
Suggested-by: Ben Dooks
Signed-off-by: Rob Jones
---
Documentation/driver-model/devres-debugfs.txt | 140 +
drivers/base/Kconfig | 18 ++
drivers/base/devres.c | 387 +
3 files changed
such as GPIOs, IRQs and
memory allocated using devm_kmalloc() without the use of intrusive debug
tools.
Rob Jones (1):
Managed Devices devres_debugfs file system
Documentation/driver-model/devres-debugfs.txt | 140 +
drivers/base/Kconfig | 18 ++
drivers/base
indication is provided as to which particular request failed.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/gpio/devres.c | 57 +
include/linux/gpio.h |4
2 files changed, 61 insertions(+)
diff --git a/drivers/gpio
Change gpio-reulator-probe() to use managed resources.
Add new managed resource functions as needed to achieve this.
Amend the following functions:
devm_kstrdup()
gpio_regulator_probe()
Add the following functions:
devm_kmemdup()
devm_gpio_request_array()
devm_gpio_free_array()
Remove the fol
Add function devm_kmemdup().
Rationalise with devm_kstrdup() to avoid code duplication.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/base/devres.c | 42 ++
include/linux/device.h |2 ++
2 files changed, 36 insertions(+), 8
Use managed resource functions for all resource allocations in
gpio_regulator_probe().
Remove gpio_regulator_remove() as it is now redundant.
Reviewed-by: Ian Molton
Signed-off-by: Rob Jones
---
drivers/regulator/gpio-regulator.c | 71
1 file changed, 24
Are there any other responses on this please? It seems pretty
uncontentious. Maybe everyone was at LinuxCon last week.
On 18/08/14 12:50, Steven Whitehouse wrote:
Hi,
On 18/08/14 12:40, Rob Jones wrote:
Despite the fact that these functions have been around for years, they
are
little used
Reduce boilerplate code by using seq_open_private() instead of seq_open()
Signed-off-by: Rob Jones
---
fs/ocfs2/dlmglue.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 6bd690b..503184d 100644
--- a/fs
freed.
Signed-off-by: Rob Jones
---
fs/ocfs2/cluster/netdebug.c | 78 +++
1 file changed, 19 insertions(+), 59 deletions(-)
diff --git a/fs/ocfs2/cluster/netdebug.c b/fs/ocfs2/cluster/netdebug.c
index 73ba819..27d1242 100644
--- a/fs/ocfs2/cluster
outside the remit of this patch series.
Signed-off-by: Rob Jones
Rob Jones (3):
fs: ocfs2: use seq_open_private() not seq_open()
fs: ocfs2: use seq_open_private() not seq_open()
fs: ocfs2: Use __seq_open_private() not seq_open()
fs/ocfs2/cluster/netdebug.c | 78
Reduce boilerplate code by using seq_open_private() instead of seq_open()
Signed-off-by: Rob Jones
---
fs/ocfs2/dlm/dlmdebug.c | 39 ++-
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/fs/ocfs2/dlm/dlmdebug.c b/fs/ocfs2/dlm/dlmdebug.c
index
Aargh! Scratch this patch. I got carried away with the error checking in
the examples. The "if (IS_ERR(p))" check is redundant. I'll remove it
and resubmit.
On 15/08/14 15:10, Rob Jones wrote:
Despite the fact that these functions have been around for years, they are
little use
Despite the fact that these functions have been around for years, they are
little used (only 15 uses in 13 files at the preseht time) even though
many other files use work-arounds to achieve the same result.
By documenting them, hopefully they will become more widely used.
Signed-off-by: Rob
Many modules use seq_open() when seq_open_private() or
__seq_open_private() would be more appropriate and result in
simpler, cleaner code.
This patch sequence changes those instances in IPC, MM and LIB.
Rob Jones (4):
ipc: Use __seq_open_private() instead of seq_open()
mm: Use
: Rob Jones
---
ipc/util.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/ipc/util.c b/ipc/util.c
index 2eb0d1e..98cb51d 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -892,28 +892,16 @@ static const struct seq_operations sysvipc_proc_seqops = {
static
Using __seq_open_private() removes boilerplate code from slabstats_open()
The resultant code is shorter and easier to follow.
This patch does not change any functionality.
Signed-off-by: Rob Jones
---
mm/slab.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions
Using seq_open_private() removes boilerplate code from vmalloc_open().
The resultant code is shorter and easier to follow.
However, please note that seq_open_private() call kzalloc() rather than
kmalloc() which may affect timing due to the memory initialisation overhead.
Signed-off-by: Rob
Using seq_open_private() removes boilerplate code from ddebug_proc_open()
The resultant code is shorter and easier to follow.
This patch does not change any functionality.
Signed-off-by: Rob Jones
---
lib/dynamic_debug.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions
On 29/08/14 20:14, Andrew Morton wrote:
On Fri, 29 Aug 2014 17:06:36 +0100 Rob Jones wrote:
Many modules use seq_open() when seq_open_private() or
__seq_open_private() would be more appropriate and result in
simpler, cleaner code.
This patch sequence changes those instances in IPC, MM and
also for __seq_open_private()
Signed-off-by: Rob Jones
---
fs/seq_file.c|4 ++--
include/linux/seq_file.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 1d641bb..dc2dfec 100644
--- a/fs/seq_file.c
+++ b/fs
Resubmitting - mistranscribed Alexander Viro's email address.
On 01/09/14 14:13, Rob Jones wrote:
also for __seq_open_private()
Signed-off-by: Rob Jones
---
fs/seq_file.c|4 ++--
include/linux/seq_file.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
also for __seq_open_private()
Resubmitted due to email address typo.
Signed-off-by: Rob Jones
---
fs/seq_file.c|4 ++--
include/linux/seq_file.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 1d641bb..dc2dfec
ed int" at most.
As almost all in-kernel lengths.
Alexey
--
Rob Jones
Codethink Ltd
mailto:rob.jo...@codethink.co.uk
tel:+44 161 236 5575
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On 01/09/14 15:13, Alexey Dobriyan wrote:
On Mon, Sep 1, 2014 at 4:54 PM, Rob Jones wrote:
On 01/09/14 14:43, Alexey Dobriyan wrote:
void *__seq_open_private(struct file *f, const struct seq_operations
*ops,
- int psize)
+ size_t psize)
It should be "unsigned int" a
On 01/09/14 16:36, Al Viro wrote:
On Mon, Sep 01, 2014 at 02:17:08PM +0100, Rob Jones wrote:
void *__seq_open_private(struct file *f, const struct seq_operations *ops,
- int psize)
+ size_t psize)
It is a horrible limitation to impose, indeed. Why, a lousy
2
On 01/09/14 22:22, Al Viro wrote:
On Mon, Sep 01, 2014 at 03:38:51PM +0100, Rob Jones wrote:
kmalloc where it is expected to be a size_t.
Which is a mistake too because allocations are never that large.
Yet.
*raised eyebrow*
You do realize that kmalloc() gives physically contiguous
Does anyone have any feedback on this?
I would have thought it was quite uncontroversial.
On 29/07/14 18:39, Rob Jones wrote:
Create a function seq_open_priv() that is identical to seq_open() except
that it accepts a void * parameter that it stores in the private field
of the struct seq_file
On 06/08/14 17:02, Al Viro wrote:
On Tue, Jul 29, 2014 at 06:39:53PM +0100, Rob Jones wrote:
At the moment these consumers have to obtain the struct seq_file pointer
(stored by seq_open() in file->private_data) and then store a pointer to
their own data in the private field of the str
On 06/08/14 20:14, Eric W. Biederman wrote:
Rob Jones writes:
On 06/08/14 17:02, Al Viro wrote:
On Tue, Jul 29, 2014 at 06:39:53PM +0100, Rob Jones wrote:
At the moment these consumers have to obtain the struct seq_file pointer
(stored by seq_open() in file->private_data) and then st
Hi Steve,
On 07/08/14 14:32, Steven Whitehouse wrote:
Hi,
On 07/08/14 13:58, Rob Jones wrote:
[snip]
On a related subject, Having looked at a few uses of seq_file, I must
say that some users seem to make assumptions about the internal
workings of the module. Dangerous behaviour as only some
On 07/08/14 15:09, Rob Jones wrote:
Hi Steve,
On 07/08/14 14:32, Steven Whitehouse wrote:
Hi,
On 07/08/14 13:58, Rob Jones wrote:
[snip]
On a related subject, Having looked at a few uses of seq_file, I must
say that some users seem to make assumptions about the internal
workings of the
On 07/08/14 15:22, Steven Whitehouse wrote:
Hi,
On 07/08/14 15:16, Rob Jones wrote:
On 07/08/14 15:09, Rob Jones wrote:
Hi Steve,
On 07/08/14 14:32, Steven Whitehouse wrote:
Hi,
On 07/08/14 13:58, Rob Jones wrote:
[snip]
On a related subject, Having looked at a few uses of seq_file
Despite the fact that these functions have been around for years, they are
little used (only 15 uses in 13 files at the preseht time) even though
many other files use work-arounds to achieve the same result.
By documenting them, hopefully they will become more widely used.
Signed-off-by: Rob
I'm afraid too many other things have been landing on my plate and I
don't think I will be able to get on this for the foreseeable future,
sorry about this.
On 11/07/14 11:07, Javier Martinez Canillas wrote:
Hello Rob,
On Fri, Jul 11, 2014 at 12:03 PM, Rob Jones wrote:
On 11/0
Despite the fact that these functions have been around for years, they are
little used (only 15 uses in 13 files at the preseht time) even though
many other files use work-arounds to achieve the same result.
By documenting them, hopefully they will become more widely used.
Signed-off-by: Rob
Reduce boilerplate code by using __seq_open_private() instead of seq_open().
This function has been around, undocumented, for years. It can simplify
the set up code for seq file operations.
Signed-off-by: Rob Jones
---
This patch was originally submitted on 12th September as part 2/2.
Part 1
77 matches
Mail list logo