headers
Michael Kerrisk | 2 Feb 19:59
Picon

Re: A typo in the wcslen man page.

On Mon, Dec 19, 2011 at 2:24 AM, carado <carado@...> wrote:
> Hello.
>
> I believe I have found a typo in the man page of wcslen (section 3).
> It says “the terminating null wide chharacter” with “chharacter” instead of
> “character”.
>
> Thank you for taking the time to read this,

Thanks! Fixed.

Cheers,

Michael

--

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Michael Kerrisk | 2 Feb 20:04
Picon

Re: Typo in scanf

On Fri, Nov 18, 2011 at 8:31 PM, Alain <alainb06@...> wrote:
> There is a typo in the example given under "Note" section.
>
> Sorry I saw just now that there is a very easy way to report that by mail...
> I already files the report (and details such as version used = Ubuntu
> 10.04.3) here :
>
> https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/891854
>
> Typo is:
>
> fprintf(stderr, "No matching characters\n"):
>
> Should be instead
>
> fprintf(stderr, "No matching characters\n");
>
>
> ( ';' semicolon terminates an C instruction, and not ':' colon )
>
> I also made a suggestion (see bug report), to change the example using the
> 'm' modifier as 'a' seems rather dangerous and obsolete.
> This second part is just a suggestion (subject to discussion) whereas the
> typo is really there and makes compiling without errors impossible.
>
> Best regards.
> Alain BENEDETTI

Thanks Alain. Fixed!
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 3 Feb 09:13

[Bug 13608] Invalid default in bridge-nf-filter-vlan-tagged description

https://bugzilla.kernel.org/show_bug.cgi?id=13608

Michael Kerrisk <mtk.manpages@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mtk.manpages@...
         Resolution|                            |WILL_NOT_FIX

--- Comment #2 from Michael Kerrisk <mtk.manpages@...> 
2012-02-03 08:13:30 ---
Closing, as this doesn't appear to be a bug in a man page. If I've missed
something, please reopen, or reopen and assign to the appropriate maintainer.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Mike Frysinger | 3 Feb 11:29
Picon
Favicon
Gravatar

Re: [RESEND][PATCH] Mark thread stack correctly in proc/<pid>/maps

On Friday 03 February 2012 03:01:35 KOSAKI Motohiro wrote:
> > Right now MAP_STACK does not mean anything since it is ignored. The
> > intention of this behaviour change is to make MAP_STACK mean that the
> > map is going to be used as a stack and hence, set it up like a stack
> > ought to be. I could not really think of a valid case for fixed size
> > stacks; it looks like a limitation in the pthread implementation in
> > glibc rather than a feature. So this patch will actually result in
> > uniform behaviour across threads when it comes to stacks.
> > 
> > This does change vm accounting since thread stacks were earlier
> > accounted as anon memory.
> 
> The fact is, now process stack and pthread stack clearly behave
> different dance. libc don't expect pthread stack grow automatically.
> So, your patch will break userland. Just only change display thing.

does it though ?  glibc doesn't keep track of the unused address space ... 
that's what the kernel is for.  pthread_attr_setstacksize explicitly operates 
on the *minimum* stack size, not the *exact* size.

where exactly do you think userland would break ?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_attr_setstacksize.html
-mike
Permalink | Reply | 0 comments |
headers
Siddhesh Poyarekar | 3 Feb 19:34
Picon
Gravatar

Re: [RESEND][PATCH] Mark thread stack correctly in proc/<pid>/maps

On Fri, Feb 3, 2012 at 1:31 PM, KOSAKI Motohiro
<kosaki.motohiro@...> wrote:
> The fact is, now process stack and pthread stack clearly behave
> different dance. libc don't expect pthread stack grow automatically.
> So, your patch will break userland. Just only change display thing.

The change should not make thread stacks (as implemented by glibc)
grow automatically in the general case since it has to implement guard
page(s) at the beginning of the mapped memory for stack using
mprotect(top, size, PROT_NONE). Due to this, the program will crash
before it ever has a chance to cause a page fault to make the stack
grow. This is of course assuming that the program doesn't purposely
jump over the guard page(s) by setting %sp beyond them and then
causing a page fault. So the only case in which a thread stack will
grow automatically is if the stackguard is set to 0:

http://pubs.opengroup.org/onlinepubs/007904975/functions/pthread_attr_setguardsize.html

I have also dropped an email on the libc-alpha list here to solicit
comments from libc maintainers on this:

http://sourceware.org/ml/libc-alpha/2012-02/msg00036.html

--

-- 
Siddhesh Poyarekar
http://siddhesh.in
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 26 comments |
headers
Elie De Brauwer | 7 Feb 08:48
Picon
Gravatar

proc(5) and definition of loadavg

Hello all,

I've got a small suggestion related to man 5 proc (
http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html ).
If you go to /proc/loadavg it states

<quote>
 The fourth field consists of two numbers separated by a slash (/).
The first of these is the number of currently executing kernel
scheduling entities (processes, threads); this will be less than or
equal to the number of CPUs.  The value after the slash is the number
of kernel scheduling entities that currently exist on the system.
</quote>

When I take a look at /proc/loadavg this seems to make sense:

edb <at> lapedb:~$ cat /proc/loadavg
0.04 0.65 0.59 1/284 8102

However, suppose I run 4 background jobs of 'yes bla > /dev/null &'

edb <at> lapedb:~$ yes bla > /dev/null &
[1] 8111
edb <at> lapedb:~$ yes bla > /dev/null &
[2] 8112
edb <at> lapedb:~$ yes bla > /dev/null &
[3] 8113
edb <at> lapedb:~$ yes bla > /dev/null &
[4] 8114
edb <at> lapedb:~$ cat /proc/loadavg
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Kerrisk | 7 Feb 18:22
Picon

Re: proc(5) and definition of loadavg

Hello Elie,

On Tue, Feb 7, 2012 at 8:48 PM, Elie De Brauwer <eliedebrauwer@...m> wrote:
> Hello all,
>
> I've got a small suggestion related to man 5 proc (
> http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html ).
> If you go to /proc/loadavg it states
>
> <quote>
>  The fourth field consists of two numbers separated by a slash (/).
> The first of these is the number of currently executing kernel
> scheduling entities (processes, threads); this will be less than or
> equal to the number of CPUs.  The value after the slash is the number
> of kernel scheduling entities that currently exist on the system.
> </quote>
>
> When I take a look at /proc/loadavg this seems to make sense:
>
> edb <at> lapedb:~$ cat /proc/loadavg
> 0.04 0.65 0.59 1/284 8102
>
> However, suppose I run 4 background jobs of 'yes bla > /dev/null &'
>
> edb <at> lapedb:~$ yes bla > /dev/null &
> [1] 8111
> edb <at> lapedb:~$ yes bla > /dev/null &
> [2] 8112
> edb <at> lapedb:~$ yes bla > /dev/null &
> [3] 8113
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Kerrisk | 7 Feb 18:24
Picon

Re: documentation typo

On Mon, Feb 6, 2012 at 2:19 PM, Christopher Patton
<chpatton013@...> wrote:
> man close
> second paragraph under DESPRIPTION:
> "[...] are freed; if  the descriptor was [...]"
> two spaces between if and the

Christopher,

This is just the output of groff--it happens to add the space padding
there to right justify the text. Or have I missed your point?

Thanks,

Michael

--

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Michael Kerrisk | 7 Feb 19:25
Picon

Re: aio_error query

Hi Jon,

On Sun, Jan 22, 2012 at 10:48 AM, Jon Grant <jg@...> wrote:
> Hello
>
> http://www.kernel.org/doc/man-pages/online/pages/man3/aio_error.3.html
>
> Is this really positive?

Do you have some counter-evidence?

> errno is an int, and the values I think are not
> guaranteed to be positive (like with glibc). I work on a system where they
> are all negative.

Error numbers are all positive. I don't understand your last sentence above.

Cheers,

Michael

>       *  A positive error, if the asynchronous I/O operation failed. This is
> the
>          same value that would have been stored in the errno variable in the
> case of
>          a synchronous read(2), write(2), fsync(2), or fdatasync(2) call.
>
> Best regards, Jon

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Kerrisk | 7 Feb 19:27
Picon

Re: errno(3) link on pages which set errno

Hi Jon,

On Sun, Jan 22, 2012 at 10:40 AM, Jon Grant <jg@...> wrote:
> Hello
>
> Could pages like aio_read and others which may set errno, have a link in the
> SEE ALSO section to errno(3) please.  There are quite a lot of pages that
> could have this SEE ALSO link.

Well, in theory, probably 90% of section2 and 3 pages could have that
link. I think it's not useful to do that.

Cheers,

Michael

--

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane