Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Fri, 04 Mar 2016 15:09:09 +0100
Johannes Stezenbach  escreveu:

> On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote:
> > 
> > 3) I tried to use a .. cssclass, as Johannes suggested, but
> > I was not able to include the CSS file. I suspect that this is
> > easy to fix, but I want to see if the cssclass will also work for
> > the pdf output as well.  
> 
> "cssclass" was (I think) a custom role defined in the example,
> unless you also have defined a custom role you can use plain "class".
> I have not looked deeper into the theming and template stuff.

Well, it accepted cssclass for html (well, it didn't find the
templates - so I guess it is just me failing to understand how to tell
sphinx to get the stylesheet), but it rejects it for latexPDF.

> 
> > 4) It seems that it can't produce nested tables in pdf:
> > 
> > Markup is unsupported in LaTeX:
> > v4l-table-within-table:: nested tables are not yet implemented.
> > Makefile:115: recipe for target 'latexpdf' failed  
> 
> This:
> http://www.sphinx-doc.org/en/stable/markup/misc.html#tables
> 
> suggests you need to add the tabularcolumns directive
> for complex tables.
> 
> BTW, as an alternative to the ASCII-art input
> there is also support for CSV and list tables:
> http://docutils.sourceforge.net/docs/ref/rst/directives.html#table

I converted one of the big tables to CSV. At least now it recognized
it as a table. Yet, the table was very badly formated:

https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html

This is how this table should look like:
https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html

Also, as this table has merged cells at the legend. I've no idea how
to tell sphinx to do that on csv format.

The RST files are on this git tree:
https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/

Regards,
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

[PATCH] fat: add config option to set UTF-8 mount option by default

[Maciej S. Szmigiero]

FAT has long supported its own default file name encoding
config setting, separate from CONFIG_NLS_DEFAULT.

However, if UTF-8 encoded file names are desired FAT
character set should not be set to utf8 since this would
make file names case sensitive even if case insensitive
matching is requested.
Instead, "utf8" mount options should be provided to enable
UTF-8 file names in FAT file system.

Unfortunately, there was no possibility to set the default
value of this option so on UTF-8 system "utf8" mount option
had to be added manually to most FAT mounts.

This patch adds config option to set such default value.

Signed-off-by: Maciej S. Szmigiero 
---
 Documentation/filesystems/vfat.txt |  7 ---
 fs/fat/Kconfig | 18 +-
 fs/fat/inode.c |  8 +++-
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/Documentation/filesystems/vfat.txt 
b/Documentation/filesystems/vfat.txt
index 223c32171dcc..cf51360e3a9f 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -56,9 +56,10 @@ iocharset= -- Character set to use for converting 
between the
 you should consider the following option instead.
 
 utf8=   -- UTF-8 is the filesystem safe version of Unicode that
-is used by the console.  It can be enabled for the
-filesystem with this option. If 'uni_xlate' gets set,
-UTF-8 gets disabled.
+is used by the console. It can be enabled or disabled
+for the filesystem with this option.
+If 'uni_xlate' gets set, UTF-8 gets disabled.
+By default, FAT_DEFAULT_UTF8 setting is used.
 
 uni_xlate= -- Translate unhandled Unicode characters to special
 escaped sequences.  This would let you backup and
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 182f9ffe2b51..3ff1772f612e 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
  that most of your FAT filesystems use, and can be overridden
  with the "iocharset" mount option for FAT filesystems.
  Note that "utf8" is not recommended for FAT filesystems.
- If unsure, you shouldn't set "utf8" here.
+ If unsure, you shouldn't set "utf8" here - select the next option
+ instead if you would like to use UTF-8 encoded file names by default.
  See  for more information.
 
  Enable any character sets you need in File Systems/Native Language
  Support.
+
+config FAT_DEFAULT_UTF8
+   bool "Enable FAT UTF-8 option by default"
+   depends on VFAT_FS
+   default n
+   help
+ Set this if you would like to have "utf8" mount option set
+ by default when mounting FAT filesystems.
+
+ Even if you say Y here can always disable UTF-8 for
+ particular mount by adding "utf8=0" to mount options.
+
+ Say Y if you use UTF-8 encoding for file names, N otherwise.
+
+ See  for more information.
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index a5599052116c..f2504c2107fb 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1127,7 +1127,7 @@ static int parse_options(struct super_block *sb, char 
*options, int is_vfat,
}
opts->name_check = 'n';
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK =  0;
-   opts->utf8 = opts->unicode_xlate = 0;
+   opts->unicode_xlate = 0;
opts->numtail = 1;
opts->usefree = opts->nocase = 0;
opts->tz_set = 0;
@@ -1135,6 +1135,12 @@ static int parse_options(struct super_block *sb, char 
*options, int is_vfat,
opts->errors = FAT_ERRORS_RO;
*debug = 0;
 
+#ifdef CONFIG_FAT_DEFAULT_UTF8
+   opts->utf8 = is_vfat;
+#else
+   opts->utf8 = 0;
+#endif
+
if (!options)
goto out;
 
--
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: [PATCH] Documentation: update the devices.txt documentation

[Greg Kroah-Hartman]

On Fri, Feb 19, 2016 at 09:17:36PM +0100, Linus Walleij wrote:
> Alan is no longer maintaining this list through the Linux assigned
> numbers authority. Make it a collective document by referring to
> "the maintainers" in plural throughout, and naming the chardev and
> block layer maintainers in particular as parties of involvement.
> Cut down and remove some sections that pertained to the process of
> maintaining the list at lanana.org and contacting Alan directly.
> 
> Make it clear that this document, in the kernel, is the master
> document.
> 
> Also move paragraphs around so as to emphasize dynamic major number
> allocation.
> 
> Remove paragraph on 2.6 deprecation, that tag no longer appears
> anywhere in the file.
> 
> Cc: Jonathan Corbet 
> Cc: Linus Torvalds 
> Cc: Greg Kroah-Hartman 
> Cc: Alan Cox 
> Cc: Arnd Bergmann 
> Cc: Jens Axboe 
> Signed-off-by: Linus Walleij 
> ---
> Greg I guess this can go through the drivercore tree?

Yes, I'll take it now, thanks.

greg k-h
--
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: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

Hi Tejun,

On Sat, Mar 5, 2016 at 6:22 PM, Tejun Heo  wrote:
> Hello, Parav.
>
> On Sat, Mar 05, 2016 at 04:45:09PM +0530, Parav Pandit wrote:
>> Design that remains same from v6 to v10.
>>   * spin lock is still fine grained at cgroup level instead of one
>> global shared lock among all cgroups.
>>  In future it can be optimized further to do per cpu or using
>> single lock if required.
>>   * file type enums are still present for max and current, as
>> read/write call to those files is already taken care by common
>> functions with required if/else.
>>   * Resource limit setting is as it is, because number of devices are
>> in range of 1 to 4 count in most use cases (as explained in
>> documentation), and its not hot path.
>
> 1 and 2 are not okay.
For (1) shall I have one spin lock that is uses across multiple
hierarchy and multiple cgroup.
Essentially one global lock among all cgroup. During hierarchical
charging, continue to use same lock it at each level.
Would that work in this first release?

Can you please review the code for (2), I cannot think of any further
helper functions that I can write.
For both the file types, all the code is already common.
file types are used only to find out whether to reference max variable
or usage variable in structure.
Which can also be made as array, but I do not want to lose the code
readability for that little gain.
What exactly is the issue in current implementation? You just
mentioned that "its not good sign".
Its readable, simple and serves the purpose, what am I missing?

> 3 is fine but resource [un]charging is not hot path?
charge/uncharge is hot path from cgroup perspective.
Considering 1 to 4 devices in system rpool list would grow upto 4
entry deep at each cgroup level.
I believe this is good enough to start with. O complexity wise its
O(N). where N is number of devices in system.


>
> Thanks.
>
> --
> tejun
--
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: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Tilman Schmidt]

Am 04.03.2016 um 17:18 schrieb Paul Bolle:
> [Added Tilman and Christoph.]
> 
> On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
>> I actually did more patches that I ended up not submitting:
>>
>> * move hisax to staging
>> * remove i4l support from gigaset
> 
> For the record: I have no reason to object a patch that does that. (I'm
> not aware anyone complained when gigaset switched its default from i4l
> to capi. By now all relevant distributions should use our capi driver.)

No objection from me either. When the Gigaset driver is built for CAPI
it can still be used from i4l applications via capidrv with no loss of
functionality. That was a primary goal of the CAPI port.

>> * move i4l core to staging

That's a different story. Removing i4l support will actually remove a
userspace visible feature.

> On a local tree I have two (draft) patches that do some related
> preliminary work:
> - isdnhdlc: move into separate directory
> - mISDN: NETJet: stop selecting ISDN_I4L
> 
> These trivial patches untangle mISDN and i4l.

That would be a good thing regardless of any decision on the future of
the i4l userspace interface.

> For my part I'm surprised that anyone is still using it. But apparently
> the hardware that required commit 19cebbcb04c8 and 3460baa62068  (which
> I'm unfamiliar with) is still operational. And since there never has
> been, as far as I know, a global i4l to capi migration nor a global i4l
> (and capi) to mISDN migration it might be that some people are stuck on
> i4l drivers for their hardware. Perhaps that explains Cristoph's
> commits.

The trouble is that mISDN never cared about migration or backward
compatibility. So while users of i4l applications have no problem with
i4l drivers being ported to CAPI and dropping native i4l support, they
do have a problem with drivers making that move to mISDN.

That is the situation of the hisax driver today. mISDN started as a
project to migrate hisax to CAPI but regrettably dropped that goal in
favor of a newly invented API leaving old i4l based applications behind.
As a consequence, owners of HiSAX type adapters are in fact stuck with
the old hisax driver if they want to continue using i4l userspace tools.

In my opinion, i4l, capidrv and hisax need to stay in the supported part
for the time being as they are still actively used. Native i4l support
can and should be dropped for hardware with CAPI drivers (ie. gigaset)
but not for hardware with only mISDN drivers (ie. hisax). And finally,
ISDN_CAPI_CAPIDRV should be enabled automatically if both ISDN_I4L and
ISDN_CAPI are enabled, ie. something like:

--- a/drivers/isdn/capi/Kconfig
+++ b/drivers/isdn/capi/Kconfig
@@ -27,8 +27,8 @@ config ISDN_CAPI_MIDDLEWARE
  your ISP, say Y here.

 config ISDN_CAPI_CAPIDRV
-   tristate "CAPI2.0 capidrv interface support"
-   depends on ISDN_I4L
+   tristate
+   default ISDN_I4L
help
  This option provides the glue code to hook up CAPI driven cards to
  the legacy isdn4linux link layer.  If you have a card which is


Jm2c,
Tilman

-- 
Tilman Schmidt  E-Mail: til...@imap.cc
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

Hi Tejun,

I would like to submit patch v10.
Can you please confirm that you are ok (or not) with the current
design and below changes should be good enough?
I am ok if you directly want to jump to review v10 too.

Changes from v9:
  * Included documentation of resources in v2.txt and v1.txt
  * Fixed issue of race condition of process migration during charging stage.
  * Fixed comments and code to adhere to CodingStyle.
  * Simplified and removed support to charge/uncharge multiple resource.
  * Fixed removed refcnt with usage_num that tracks how many
resources are unused to trigger freeing the object.
  * Removed inline for query_limit and other function as its not necessary.

Design that remains same from v6 to v10.
  * spin lock is still fine grained at cgroup level instead of one
global shared lock among all cgroups.
 In future it can be optimized further to do per cpu or using
single lock if required.
  * file type enums are still present for max and current, as
read/write call to those files is already taken care by common
functions with required if/else.
  * Resource limit setting is as it is, because number of devices are
in range of 1 to 4 count in most use cases (as explained in
documentation), and its not hot path.

Parav



On Thu, Mar 3, 2016 at 8:19 AM, Parav Pandit  wrote:
> Hi Tejun, Haggai,
>
> On Thu, Mar 3, 2016 at 1:28 AM, Parav Pandit  wrote:
 + rpool->refcnt--;
 + if (rpool->refcnt == 0 && rpool->num_max_cnt == 
 pool_info->table_len) {
>>>
>>> If the caller charges 2 and then uncharges 1 two times, the refcnt
>>> underflows?  Why not just track how many usages are zero?
>>>
>> This is certainly must fix bug. Changed refcnt to usage_sum and changed to do
>> usage_sum -= num during uncharging
>> and
>> usage_sum += num during charing.
>
> This is not sufficient as css_get() and put are done only once per
> call, which leads to similar problem as of refcnt.
> As I think more, I realised that this particular test is missing that
> resulted in this related bug, I realize that we don't have use case to
> have "num" field from the IB stack side.
> For bulk free IB stack will have to keep track of different or same
> rdmacg returned values to call uncharge() with right number of
> resources, all of that complexity just doesn't make sense and not
> required.
> So as first step to further simplify this, I am removing "num" input
> field from charge and uncharge API.
--
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