Re: scripts/kernel-doc: no warning or error on lots of missing function parameters

2017-12-29 Thread Randy Dunlap 
On 12/29/2017 06:28 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 29 Dec 2017 18:17:08 -0800
> Randy Dunlap  escreveu:
> 
>> In linux-next-20171222, this message:
>>
>>  print STDERR "${file}:$.: warning:" .
>>  " No description found for parameter '$param'\n";
>>
>> has roughly/approximately been replaced with:
>>
>>  print STDERR
>>  "${file}:$.: warning: Function parameter or member '$param' not 
>> described in '$declaration_name'\n";
>>
>>
>> Using linux-next-20171222, with its ("new") scripts/kernel-doc, I see
>>
>>> grep -c  not.described doc005.out
>> 86
>>
>> but if I use scripts/kernel-doc from linux-4.15-rc5 (in 
>> linux-next-20171222), I see
>>
>>> grep -c No.description.found doc006.out
>> 305
>>
>>
>> This is not good.
> 
> Actually, if you look at the messages produced before linux-next, you'll
> notice that the *same* error is reported multiple times.
> 
> The problem is that some headers are included multiple times:
> 
> $ git grep include/net/cfg80211.h Documentation/|wc -l
> 111
> 
> If you look inside Documentation/driver-api/80211/cfg80211.rst,
> you'll see:
> 
> .. kernel-doc:: include/net/cfg80211.h
>:functions: ieee80211_channel_flags
> 
> .. kernel-doc:: include/net/cfg80211.h
>:functions: ieee80211_channel
> 
> ...
> 
> With the old incarnation of kernel-doc, every time it parses an
> script, it generate warnings for all symbols, *including* the
> ones that aren't part of the kernel-doc output. The one at
> linux-next has an extra logic that, when "functions" is used,
> it will only output warnings for the symbol mentioned there,
> with prevents it to repeat the same error report every time.
> 
> I suspect that, if you do:
> 
>   grep No.description.found doc006.out|sort|uniq|wc -l

That (copy-and-pasted to prevent typos) gives me 304 (i.e., one less).

> you'll see that the number of errors on 4.15-rc5 is actually
> smaller than on linux-next, as it now reports missing symbols
> on nested structs and unions.

There are definitely missing parameter descriptions that are not being
reported in linux-next.  Here's one such example (still working in
linux-next-20171222, just with differing versions of scripts/kernel-doc).

kernel-doc from 4.15-rc5:

../net/core/dev.c:6400: warning: No description found for parameter 'extack'
../net/core/dev.c:6423: warning: No description found for parameter 'extack'

kernel-doc from linux-next-20171222:

{those reports are missing but the descriptions are also missing}


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scripts/kernel-doc: no warning or error on lots of missing function parameters

2017-12-29 Thread Mauro Carvalho Chehab 
Em Fri, 29 Dec 2017 18:17:08 -0800
Randy Dunlap  escreveu:

> In linux-next-20171222, this message:
> 
>   print STDERR "${file}:$.: warning:" .
>   " No description found for parameter '$param'\n";
> 
> has roughly/approximately been replaced with:
> 
>   print STDERR
>   "${file}:$.: warning: Function parameter or member '$param' not 
> described in '$declaration_name'\n";
> 
> 
> Using linux-next-20171222, with its ("new") scripts/kernel-doc, I see
> 
> > grep -c  not.described doc005.out
> 86
> 
> but if I use scripts/kernel-doc from linux-4.15-rc5 (in linux-next-20171222), 
> I see
> 
> > grep -c No.description.found doc006.out
> 305
> 
> 
> This is not good.

Actually, if you look at the messages produced before linux-next, you'll
notice that the *same* error is reported multiple times.

The problem is that some headers are included multiple times:

$ git grep include/net/cfg80211.h Documentation/|wc -l
111

If you look inside Documentation/driver-api/80211/cfg80211.rst,
you'll see:

.. kernel-doc:: include/net/cfg80211.h
   :functions: ieee80211_channel_flags

.. kernel-doc:: include/net/cfg80211.h
   :functions: ieee80211_channel

...

With the old incarnation of kernel-doc, every time it parses an
script, it generate warnings for all symbols, *including* the
ones that aren't part of the kernel-doc output. The one at
linux-next has an extra logic that, when "functions" is used,
it will only output warnings for the symbol mentioned there,
with prevents it to repeat the same error report every time.

I suspect that, if you do:

grep No.description.found doc006.out|sort|uniq|wc -l

you'll see that the number of errors on 4.15-rc5 is actually
smaller than on linux-next, as it now reports missing symbols
on nested structs and unions.

Regards,

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

scripts/kernel-doc: no warning or error on lots of missing function parameters

2017-12-29 Thread Randy Dunlap 
In linux-next-20171222, this message:

print STDERR "${file}:$.: warning:" .
" No description found for parameter '$param'\n";

has roughly/approximately been replaced with:

print STDERR
"${file}:$.: warning: Function parameter or member '$param' not 
described in '$declaration_name'\n";


Using linux-next-20171222, with its ("new") scripts/kernel-doc, I see

> grep -c  not.described doc005.out
86

but if I use scripts/kernel-doc from linux-4.15-rc5 (in linux-next-20171222), I 
see

> grep -c No.description.found doc006.out
305


This is not good.

-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ATTENTION!!!

2017-12-29 Thread Loretta Robles 


From: Loretta Robles
Sent: Friday, December 29, 2017 1:01 PM
To: Loretta Robles
Subject: ATTENTION!!!

You have been randomly selected for a donation. Contact soriz4...@gmail.com for 
claims.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] cgroup: Update documentation reference

2017-12-29 Thread Matt Roper 
The cgroup_subsys structure references a documentation file that has been
renamed after the v1/v2 split.  Since the v2 documentation doesn't
currently contain any information on kernel interfaces for controllers,
point the user to the v1 docs.

Cc: Tejun Heo 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Matt Roper 
---
 include/linux/cgroup-defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 8b7fd8e..9f242b8 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -561,7 +561,7 @@ struct cftype {
 
 /*
  * Control Group subsystem type.
- * See Documentation/cgroups/cgroups.txt for details
+ * See Documentation/cgroup-v1/cgroups.txt for details
  */
 struct cgroup_subsys {
struct cgroup_subsys_state *(*css_alloc)(struct cgroup_subsys_state 
*parent_css);
-- 
2.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] Documentation/cgroup-v1: fix outdated programming details

2017-12-29 Thread Matt Roper 
The cgroup-v1 documentation is out of date in a few places:

 * cgroup controllers can no longer be compiled as modules since commit
   3ed80a6 ("cgroup: drop module support"); the functions and fields
   referenced here no longer exist.

 * Controllers need to create of a cgroup_subsys object named
   "_cgrp_subsys" instead of "_subsys" since commit
   073219e ("cgroup: clean up cgroup_subsys names and initialization")

Cc: Tejun Heo 
Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Matt Roper 
---
 Documentation/cgroup-v1/cgroups.txt | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/Documentation/cgroup-v1/cgroups.txt 
b/Documentation/cgroup-v1/cgroups.txt
index 308e5ff..059f706 100644
--- a/Documentation/cgroup-v1/cgroups.txt
+++ b/Documentation/cgroup-v1/cgroups.txt
@@ -523,12 +523,7 @@ Accessing a task's cgroup pointer may be done in the 
following ways:
 Each subsystem should:
 
 - add an entry in linux/cgroup_subsys.h
-- define a cgroup_subsys object called _subsys
-
-If a subsystem can be compiled as a module, it should also have in its
-module initcall a call to cgroup_load_subsys(), and in its exitcall a
-call to cgroup_unload_subsys(). It should also set its_subsys.module =
-THIS_MODULE in its .c file.
+- define a cgroup_subsys object called _cgrp_subsys
 
 Each subsystem may export the following methods. The only mandatory
 methods are css_alloc/free. Any others that are null are presumed to
-- 
2.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] dm: add asymmetric stripe target device dirver

2017-12-29 Thread liuchaowei110 
From: liuchaowei 

This asymmetric stripe target device driver can achieve better io
performance between those devices which possess different io performance

There are 2 storage device or flash devices: A and B, their sequential
read performance are 220M/s and 315M/s respectively, so their sequential
read speed ratio could be approximately equal to 2:3, if we use stripe
type to combine these two devices, their layout could be showed below:

|A1|A2|B1|B2|B3|


If we select asymmetric stripe type, their layout could be illustrated
follow:

| A1  |   B1   |


The former has 5 stripe devices and each stripe device has also equal
chunk size, e.g.: 256secs. If there is a data block which size is
1280secs, so transfer the data to this stripe device will be split
to 5 ios which io size is 256secs. But if we use the asymmetric
stripe device, it only has two stripe devices and each one has be
setting in optimal chunk size, e.g.: ratio is 2:3, the first one
optimal chunk size is 512secs, the second is 768secs.  And same
1280secs data block just only be split into two ios, this can be
achieved perfect io performance.

Change-Id: Ib188996fc844098322a6bf13ebef1ef0de38ca47
Signed-off-by: liuchaowei 
---
 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 526 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 643 insertions(+)
 create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
 create mode 100644 drivers/md/dm-asymmetric-stripe.c

diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
b/Documentation/device-mapper/asymmetric-striped.txt
new file mode 100644
index ..fb588535c49b
--- /dev/null
+++ b/Documentation/device-mapper/asymmetric-striped.txt
@@ -0,0 +1,85 @@
+dm-asymmetric-stripe
+=
+
+Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
+device across one or more underlying devices. Data is written in "chunks",
+with consecutive chunks rotating among the underlying devices. This can
+potentially provide improved I/O throughput by utilizing several physical
+devices in parallel. However, in order to gain maximum I/O performance
+between slow and fast device, there is a ratio to set up the chunk size
+among these device.
+
+Parameters:[ ]+
+: Number of underlying devices.
+: Size of each chunk of data. Must be at least as
+large as the system's PAGE_SIZE.
+: The proportion of per io size, it is the times as much
+as 1 chunk size
+: Full pathname to the underlying block-device, or a
+"major:minor" device-number.
+: Starting sector within the device.
+
+One or more underlying devices can be specified. The striped device
+size must be a multiple of the chunk size multiplied by the number of
+underlying devices. However, there is a ratio that can be set, e.g.: 2:3
+means the first one striped device optimal width size is 2 times as
+much as 1 chunk size, the second striped device is 3.
+
+
+Example scripts
+===
+
+[[
+#!/usr/bin/perl -w
+# Create a striped device across any number of underlying devices. The device
+# will be called "stripe_dev" and have a chunk-size of 128k.
+
+my $chunk_size = 128 * 2;
+my $ratio = "2:3";
+my $dev_name = "stripe_dev";
+my $num_devs = @ARGV;
+my @devs = @ARGV;
+
+if ($num_devs < 2) {
+die("Specify at least two devices\n");
+}
+
+
+$stripe_average_size = 1073741824
+$stripe_dev_size = $stripe_average_size * 5;
+
+$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
+for ($i = 0; $i < $num_devs; $i++) {
+$table .= " $devs[$i] 0";
+}
+
+`echo $table | dmsetup create $dev_name`;
+]]
+
+
+Why asymmetric striped
+===
+Considering one case:
+There are 2 storage device or flash devices: A and B, their sequential
+read performance are 220M/s and 315M/s respectively, so their sequential
+read speed could be approximately equal to 2:3, if we use stripe type
+to combine these two devices, their layout could be showed below:
+
+|A1|A2|B1|B2|B3|
+
+
+If we select asymmetric stripe type, their layout could be illustrated
+follow:
+
+| A1  |   B1   |

[PATCH 2/2] dm: optimze stripe index search algorithm

2017-12-29 Thread liuchaowei110 
From: liuchaowei 

The previous stripe index search algorithm use sequential search and
it's very slow if there are many and many physical storage devices.

The new alrogithm save the stripe index into stripe node structure,
and this driver will fetch stripe index from stripe node pointer
directly, faster than sequential search from an array

Change-Id: Ia1b3e01d54484fd40b82c52c0777ff36aac721b3
Signed-off-by: liuchaowei 
---
 drivers/md/dm-asymmetric-stripe.c | 40 ++-
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/md/dm-asymmetric-stripe.c 
b/drivers/md/dm-asymmetric-stripe.c
index ead77ff25c6b..4902fd6c4674 100644
--- a/drivers/md/dm-asymmetric-stripe.c
+++ b/drivers/md/dm-asymmetric-stripe.c
@@ -34,6 +34,11 @@
 
 typedef struct asymmetric_stripe asm_stripe;
 typedef struct asymmetric_stripe_c asm_stripe_c;
+typedef struct asymmetric_stripe_node asm_stripe_node;
+
+struct asymmetric_stripe_node {
+   uint32_t stripe_id;
+};
 
 struct asymmetric_stripe {
struct dm_dev *dev;
@@ -42,6 +47,7 @@ struct asymmetric_stripe {
sector_t physical_start;
sector_t stripe_width;
sector_t opt_io_size;
+   sector_t internal_offs;
uint32_t ratio;
 
atomic_t error_count;
@@ -63,6 +69,7 @@ struct asymmetric_stripe_c {
/* Work struct used for triggering events*/
struct work_struct trigger_event;
 
+   asm_stripe_node *node;
asm_stripe stripe[0];
 };
 
@@ -99,10 +106,13 @@ static int get_stripe(struct dm_target *ti,
unsigned int stripe,
char **argv)
 {
+   static uint32_t chunk_id;
unsigned long long start;
char dummy;
int ret;
unsigned int id = stripe;
+   sector_t offs_prev, size;
+   uint32_t i;
 
if (sscanf(argv[1], "%llu%c", , ) != 1)
return -EINVAL;
@@ -116,6 +126,17 @@ static int get_stripe(struct dm_target *ti,
sc->stripe[id].stripe_width = sc->avg_width * sc->stripe[id].ratio;
sc->stripe[id].opt_io_size = sc->chunk_size * sc->stripe[id].ratio;
 
+   if (id > 0) {
+   offs_prev = sc->stripe[id-1].internal_offs;
+   size = offs_prev + sc->stripe[id-1].opt_io_size;
+   } else
+   size = 0;
+
+   sc->stripe[id].internal_offs = size;
+
+   for (i = 0; i < sc->stripe[id].ratio; i++, chunk_id++)
+   sc->node[chunk_id].stripe_id = id;
+
return 0;
 }
 
@@ -127,6 +148,7 @@ static int set_stripe_ratio(struct dm_target *ti,
unsigned int i;
uint32_t r = 0, ratio;
char *tmp_ratio = ratio_str;
+   size_t len;
 
if (sizeof(sc->ratio_str) < strlen(ratio_str)) {
ti->error = "Too big stripe ratio string";
@@ -146,6 +168,13 @@ static int set_stripe_ratio(struct dm_target *ti,
r += ratio;
}
 
+   len = sizeof(asm_stripe_node) * r;
+   sc->node = kmalloc(len, GFP_KERNEL);
+   if (sc->node == NULL) {
+   ti->error = "Memory allocation for striped node failed";
+   return -ENOMEM;
+   }
+
sc->total_ratio = r;
sc->avg_width = ti->len / r;
sc->stripe_size = r * sc->chunk_size;
@@ -245,6 +274,7 @@ static int asymmetric_stripe_ctr(struct dm_target *ti,
 parse_error:
while (i--)
dm_put_device(ti, sc->stripe[i].dev);
+   kfree(sc->node);
kfree(sc);
return -EINVAL;
 }
@@ -254,6 +284,7 @@ static inline sector_t stripe_index_fetch(asm_stripe_c *sc,
uint32_t *stripe)
 {
sector_t width_offset;
+   uint32_t chunk_id;
 
if (sc->stripe_size_shift < 0)
width_offset = sector_div(*sector, sc->stripe_size);
@@ -262,11 +293,9 @@ static inline sector_t stripe_index_fetch(asm_stripe_c *sc,
*sector >>= sc->stripe_size_shift;
}
 
-   for (*stripe = 0; *stripe < sc->stripes; (*stripe)++) {
-   if (width_offset < sc->stripe[*stripe].opt_io_size)
-   break;
-   width_offset -= sc->stripe[*stripe].opt_io_size;
-   }
+   chunk_id = width_offset / sc->chunk_size;
+   *stripe = sc->node[chunk_id].stripe_id;
+   width_offset -= sc->stripe[*stripe].internal_offs;
 
return width_offset;
 }
@@ -280,6 +309,7 @@ static void asymmetric_stripe_dtr(struct dm_target *ti)
dm_put_device(ti, sc->stripe[i].dev);
 
flush_work(>trigger_event);
+   kfree(sc->node);
kfree(sc);
 }
 
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] dm: add asymmetric stripe device driver

2017-12-29 Thread liuchaowei110 
Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
device across one or more underlying devices. Data is written in "chunks",
with consecutive chunks rotating among the underlying devices. This can
potentially provide improved I/O throughput by utilizing several physical
devices in parallel. However, in order to gain maximum I/O performance
between slow and fast device, there is a ratio to set up the chunk size
among these device.

Parameters:[ ]+
: Number of underlying devices.
: Size of each chunk of data. Must be at least as
large as the system's PAGE_SIZE.
: The proportion of per io size, it is the times as much
as 1 chunk size
: Full pathname to the underlying block-device, or a
"major:minor" device-number.
: Starting sector within the device.

 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 556 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 678 insertions(+)

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html