the value returned
by SYSLOG_ACTION_SIZE_UNREAD is unchanged (i.e., assuming that the
value returned was non-zero before SYSLOG_ACTION_SIZE_UNREAD, it is
still nonzero afterward), even though a subsequent
SYSLOG_ACTION_READ_CLEAR indicates that there are zero bytes to read.
(All tests conducted with (r)s
Minchan,
On Mon, Mar 25, 2013 at 7:21 AM, Minchan Kim wrote:
>
> Some pages could be shared by several processes. (ex, libc)
> In case of that, it's too bad to reclaim them from the beginnig.
>
> This patch causes VM to keep them on memory until last task
> try to reclaim them so shared pages wil
Hello Minchan,
On Mon, Mar 25, 2013 at 7:21 AM, Minchan Kim wrote:
> These day, there are many platforms avaiable in the embedded market
> and they are smarter than kernel which has very limited information
> about working set so they want to involve memory management more heavily
> like android'
Hello Minchan,
On Mon, Mar 25, 2013 at 7:21 AM, Minchan Kim wrote:
> These day, there are many platforms avaiable in the embedded market
> and they are smarter than kernel which has very limited information
> about working set so they want to involve memory management more heavily
> like android'
> However, the interface is a quite blunt instrument. Would there be any
> virtue in extending it so that an address range could be written to
Here, I did mean to say "an *optional* address range.
Thanks,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
Obviously some more significant
fixes could be made to the document, but some of those
may not be in the "obviously correct" category.
Please apply.
Signed-off-by: Michael Kerrisk
diff --git a/Documentation/cgroups/cgroups.txt
b/Documentation/cgroups/cgroups.txt
index 4a0b64c..
Obviously some more significant
fixes need to be made to the document, but some of those
may not be in the "obvious correct" category.
Please apply.
Signed-off-by: Michael Kerrisk
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 4372e6b..
i-bin/bugreport.cgi?bug=461100.
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe li
s the signalfd() system call, new in 2.6.22.
Changes to individual pages
---
open.2
Greg Banks
Greatly expand the detail on O_DIRECT.
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug?
John,
A question at on one point:
On Wed, Oct 3, 2012 at 12:38 AM, John Stultz wrote:
> On 10/02/2012 12:39 AM, NeilBrown wrote:
[...]
>> The SIGBUS interface could have some merit if it really reduces
>> overhead. I
>> worry about app bugs that could result from the non-deterministic
>>
ranges. Here's one possible argument
against it (Jake Edge alerted me to this). If an application marked
adjacent ranges using separate system calls, that might be an
indication that the application intends to to have different access
patterns against the two ranges: one frequent, the other rar
diff.$$
if test $(cat /tmp/cdiff.$$ | wc -l) -ne 0; then
echo "====" $r_kapi $uapi
cat /tmp/cdiff.$$
fi
done
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.or
On Thu, Jul 26, 2012 at 12:46 PM, David Howells wrote:
>
> Oh, and thanks for the write up!
You're welcome. You may want to respond to comments that appear there,
such as this one
https://lwn.net/Articles/508203/
(You can sign up to receive comments on a specific article by mail)
On Thu, Jul 26, 2012 at 4:32 PM, David Howells wrote:
> Michael Kerrisk wrote:
>
>> I've not checked whether any of the below are fixed in the adjustments
>> that you made in the last 20 hours (though it looks like at least some
>> of them are not), but a little scri
On Thu, Jul 26, 2012 at 12:46 PM, David Howells wrote:
> Michael Kerrisk wrote:
>
>> >> >> 3. HEADER COMMENTS NOT RETAINED IN KAPI FILES
>> >
>> > How about the attached changes? This is a delta to the disintegrate
>> > markers
>>
On 07/10/13 16:18, Eliezer Tamir wrote:
> Add description for the SO_BUSY_POLL socket option to the socket(7) manpage.
>
> v2
> fixed typos reported by Rasmus Villemoes
Eliezer,
What's the status of this feature. A quick grep seems to show
that the feature is not yet in mainline. What is the pla
Kees,
> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions of older system calls with a 'flags'
argument bolted on to allow more flexible behavior (e.g., accept4(),
dup3(), utimens
_HUGE_SHIFT)
Maybe I am missing something obvious, but does this not conflict with
include/uapi/asm-generic/mman-common.h:
#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
# define MAP_UNINITIALIZED 0x400
...
0x4000000 == (1 << 26)
?
Thanks,
Michael
--
Michael Kerrisk Linux man-pages maintai
Hi Rusty,
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>&
lexander Viro
> Cc: "Paul E. McKenney"
> Cc: David Howells
> Cc: Thomas Gleixner
> Cc: Oleg Nesterov
> Cc: Michael Kerrisk
> Cc: Pavel Emelyanov
> CC: Cyrill Gorcunov
> Signed-off-by: Andrey Vagin
> ---
> fs/signalfd.c | 25 +
ov
> CC: Cyrill Gorcunov
>
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
rn the element to the caller, which is
> * expected to free it.
> *
> + * @queue: dequeue from a private queue, if a value is not positive
if a value is not positive ==> if value is nonpositive
> + * dequeue from a shared queue, if a value if not negative
if a value is not
/proc.txt since at least 2.6.0.
Anyway, I believe that the patch below fixes things.
Signed-off-by: Michael Kerrisk
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index a1793d6..cf4260f 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation
Thanks Andrey. Applied.
M
On 07/16/13 10:19, Andrey Vagin wrote:
> Signed-off-by: Andrey Vagin
> ---
> man2/ptrace.2 | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 0d77e3f..5fcac2b 100644
> --- a/man2/p
On 07/20/13 13:40, Al Viro wrote:
> On Thu, Mar 14, 2013 at 10:35:59AM +0100, Michael Kerrisk (man-pages) wrote:
>> Hello Al et al,
>>
>> Documenting O_PATH fell by the wayside last year
>> (http://thread.gmane.org/gmane.linux.man/2790) as I got distracted
>> with
privilege.
.SH "RETURN VALUE"
On success
.BR migrate_pages ()
-returns zero.
+returns the number of pages that cold not be moved
+(i.e., a return of zero means that all pages were successfully moved).
On error, it returns \-1, and sets
.I errno
to indicate the error.
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
migrate_pages.2
Description: Binary data
On Wed, Aug 1, 2012 at 8:00 PM, Christoph Lameter wrote:
> On Wed, 1 Aug 2012, Michael Kerrisk wrote:
>
>> Is the patch below acceptable? (I've attached the complete page as well.)
>
> Yes looks good.
Thanks for checking it!
>> See you in San Diego (?),
>
>
d here
> are from the base of that branch up to the uapi-prep tag; the automated split
> follows thereafter to the uapi-post-split tag.
In the uapi-split branch, there are now 44 empty Kbuild files. Was
that intended? Or, should these files rather be removed by your
patches?
Thanks,
Michael
On Tue, Jul 24, 2012 at 3:19 PM, David Howells wrote:
> Michael Kerrisk wrote:
>
>> In the uapi-split branch, there are now 44 empty Kbuild files. Was
>> that intended? Or, should these files rather be removed by your
>> patches?
>
> To be removed by a later patch,
On Wed, Jul 25, 2012 at 12:23 PM, David Howells wrote:
> Michael Kerrisk wrote:
>
>> A few other points that I noticed now...
>>
>> 1. GIT HISTORY COULD BE RETAINED IN SOME CASES
>> ...
>> But, as currently scripted the "new" uapi header file doe
an bluntly making the change and seeing if anybody squawks
because something breaks. If this change _had_ been instantly executed
in 3.4, then we'd have missed a chance to bring greater consistency
across systems (here, I assume that having added the EFAULT behavior,
there'd probably be resist
On Sun, Sep 30, 2012 at 7:51 PM, Linus Torvalds
wrote:
> On Sat, Sep 29, 2012 at 11:30 PM, Michael Kerrisk
> wrote:
>>
>>> I think the whole "let's deprecate this six months into the future" is
>>> unnecessary. Yes, it may well be worth doing for
timer(..., NULL, &ovalue) == getitimer(..., &ovalue)
The sensible thing is no change at all. This patch removes the
scheduled change from feature-removal-schedule.txt.
Signed-off-by: Michael Kerrisk
---
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/fe
will walk the specified
> range and unmap eligible pages so that they will be migrated on
> next touch.
This patch is mistitled. The new flag is MPOL_NOOP. That made it
difficult to find the commit in linux-next. Does it make sense to fix
the patch title before this hits mainline?
Thanks,
Micha
Christoph.
>
> Thanks,
> Sripathi.
>
> This adds the RUSAGE_THREAD option for the getrusage system call.
Sripathi,
Could you write some small piece of text for the getrusage.2 man page that
describes the intended behavior of RUSAGE_THREAD?
Thanks,
Michael
--
Michael Kerrisk
Mai
l set. This can be a useful technique for
filtering events, if the duplicate file descrip-
tors are registered with different events masks.
Seem okay Davide?
Cheers,
Michael
PS I've trimmed the part of this thread about Q6/A6, since I dealt with
that in ano
Following up after quite some time:
Davide Libenzi wrote:
> On Sat, 26 Jan 2008, Michael Kerrisk wrote:
>
>> On Jan 25, 2008 12:57 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
>>> On Thu, 24 Jan 2008, Pierre Habouzit wrote:
>>>
>>>> On Fri, Jan 18
On Tue, Feb 26, 2008 at 8:04 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> On Tue, 26 Feb 2008, Michael Kerrisk wrote:
>
> > Following up after quite some time:
> >
> > Davide Libenzi wrote:
> > > On Sat, 26 Jan 2008, Michael Kerrisk wrote:
> > &
O'Reilly have just released "Understanding the Linux Kernel"
http://www.ora.com/catalog/linuxkernel/
Cheers
Michael
- Original Message -
From: RAJESH BALAN <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 05, 2000 7:29 PM
Subject: good book on kernel
> Hi,
> Iam in
Hello David,
By the way, looking at the comments to the last version of
the pselect()/ppoll()patch, I see that the treatment of
the timeout argument is made dependent on the personality.
http://marc.theaimsgroup.com/?l=linux-kernel&m=111883591220436&w=2
I'm not sure that this is a good idea;
ect), and that *did*
show the signal handler being called. Also, I now have a test
result on Solaris 10 for pselect(), and it shows the signal
handler is called in this case.)
Cheers,
Michael
/* t_pselect.c
Michael Kerrisk, Aug 2005
*/
#if defined(__linux__) && !defined(NO_SYSCALL)
#defin
> Michael Kerrisk wrote:
> > Please consider making Linux pselect() conform to POSIX on this
> > point.
>
> There is no question the implementation will conform. But this not
> dependent on changing the syscall interface. We deliberately decided to
> not require
he flag
was known as SA_NOMASK).
I'll get something into the manual pages under BUGS.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest
tarball at ftp://ftp.win.tue.nl/pub/linux-local/manpa
> Von: Peter Chubb <[EMAIL PROTECTED]>
>
> > "Trond" == Trond Myklebust <[EMAIL PROTECTED]> writes:
>
> Trond> to den 11.08.2005 Klokka 09:48 (+1000) skreiv Peter Chubb:
> >> Hi, The LTP test fcntl23 is failing. It does, in essence, fd =
> >> open(xxx, O_RDWR|O_CREAT, 0777); if (fcntl(fd, F_
> Von: Trond Myklebust <[EMAIL PROTECTED]>
> to den 11.08.2005 Klokka 10:14 (+0200) skreiv Michael Kerrisk:
>
> > No. The behavior in Linux recently, and arbitrarily (IMO) changed:
>
> The change was NOT arbitrary.
Okay -- I'm puzzled. Two of the people that I
Trond,
> Von: Trond Myklebust <[EMAIL PROTECTED]>
>
> to den 11.08.2005 Klokka 14:27 (+0200) skreiv Michael Kerrisk:
> > And I pointed out that the existing behaviour (which is
> > still current in 2.6.13-rc4) is inconsistent:
> >
> > http://
Trond,
> to den 11.08.2005 Klokka 15:22 (+0200) skreiv Michael Kerrisk:
>
> > As noted already, I don't know much of CIFS and SAMBA.
> > But are you saying that it is sensible and consistent that
> > "a process can open a file read-write, and can't place a
racks here in
a wrapper for getrlimit(), but it seems more sensible
to make RLIMIT_NICE consistent with [gs]etpriority() --
i.e., change the RLIMIT_NICE interface in 2.6.13 before it
sees wide use in userland. What do you think?
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages S
0 -0700
> +++ l/kernel/sched.c 2005-07-28 22:55:54.0 -0700
> @@ -3231,8 +3231,8 @@ EXPORT_SYMBOL(set_user_nice);
> */
> int can_nice(const task_t *p, const int nice)
> {
> - /* convert nice value [19,-20] to rlimit style value [0,39] */
> - int nice_rlim =
P, preferably in 2.6.13.
Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
still isn't in the current glibc snapshot...
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest
t
:59.0 +0200
+++ MAINTAINERS.new 2005-07-29 13:34:46.0 +0200
@@ -1478,6 +1478,12 @@
M: [EMAIL PROTECTED]
S: Odd Fixes
+MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
+P: Michael Kerrisk
+M: [EMAIL PROTECTED]
+W: ftp://ftp.kernel.org/pub/linux/docs/man
> On 29 Jul 2005, Michael Kerrisk stated:
> > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE
> > still isn't in the current glibc snapshot...
>
> According to traffic on libc-hacker, Ulrich committed it on Jun 20
> (along with RLIMIT_RTPRIO suppo
David,
> On Fri, 2005-08-05 at 14:49 +0200, Michael Kerrisk wrote:
> > If I change your program to do something like the above, I also
> > do not see a message from the handler -- i.e., it is not being
> > called, and I'm pretty sure it should be.
>
> Hm, yes. Wha
Gidday,
The Linux man-pages maintainer, Michael Kerrisk, and the maintainer of the
French translation of man-pages, Alain Portal, proudly announce the
simultaneous release (*) of man-pages-2.75 in English original and French
translation.
The English version:
man-pages-2.75.tar.gz - man
Davide, Andrew,
I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
2.4.24-rc3, and did various tests (all on x86). Several tests
were done using the program at the foot of this mail. Various others
were done by cobbling together bits of code that I haven't included
here.
In cover
Hi Davide,
On Dec 13, 2007 10:49 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Dec 2007, Michael Kerrisk wrote:
>
> > Davide, Andrew,
> >
> > I applied Davide's v3 patchset (sent into LKML on 25 Nov) against
> > 2.4.24-rc3, and did various te
Global changes
--
abort.3
mtk, after a note by Alex Tuninga
A fairly significant rewrite to clarify operation of abort().
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look
Davide Libenzi wrote:
> On Thu, 27 Sep 2007, Michael Kerrisk wrote:
>
>> Davide,
>>
>> A further question: what is the expected behavior in the
>> following scenario:
>>
>> 1. Create a timerfd and arm it.
>> 2. Wait until M timer expirations have
Matti,
Matti Aarnio wrote:
> On Wed, Oct 03, 2007 at 08:50:09AM +0200, Michael Kerrisk wrote:
>> Davide Libenzi wrote:
>>> On Thu, 27 Sep 2007, Michael Kerrisk wrote:
>>>
>>>> Davide,
>>>>
>>>> A further question: what is the expected
Gidday,
Some news: the list [EMAIL PROTECTED] has been created for the
purpose of discussing Linux man page bugs, patches, and maintenance. To
subscribe, send a message to [EMAIL PROTECTED], with the body:
subscribe linux-man
Back to the news as usual...
I recently released man-pages-2.66.
[...]
> Please cc Michael Kerrisk <[EMAIL PROTECTED]> on future versions of
> these patches.
Yes, please. Buit note that my official address nowadays is
[EMAIL PROTECTED]
Chers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man
On Nov 30, 2007 5:04 PM, Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> [...]
>
> > Please cc Michael Kerrisk <[EMAIL PROTECTED]> on future versions of
> > these patches.
>
> Yes, please. Buit note that my official address nowadays is
>
> [EMAIL PR
.
spufs.7
Jeremy Kerr
Various updates and improvements.
--
Michael Kerrisk
Maintainer of the Linux man-pages project
(Sections 2, 3, 4, 5, and 7 of the Linux man pages)
http://www.kernel.org/doc/man-pages/
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
maintenance is supported by Google, as a Google engineer 20%
project.)
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Gidday,
Repeating some old news:
1) As from now, my address as man-pages maintainer has changed
to [EMAIL PROTECTED] (Mail to the old address will
continue to work for a while, but eventually I will close
that account.)
2) The list [EMAIL PROTECTED] has been created for
the purpose
Hey Davide,
Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
Cheers,
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Nov 22, 2007 6:34 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Nov 2007, Michael Kerrisk wrote:
>
> > Hey Davide,
> >
> > Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API...
>
> Maybe Andrew stuffed the turkey with it? :) It
Hi Davide,
[...]
> +asmlinkage long sys_timerfd_create(int clockid, int flags)
> {
> - int error;
> + int error, ufd;
> struct timerfd_ctx *ctx;
> struct file *file;
> struct inode *inode;
> - struct itimerspec ktmr;
> -
> - if (copy_from_user(&ktmr, utmr, sizeo
On Nov 23, 2007 7:38 PM, Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> On Nov 23, 2007 9:29 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > Yes, it's disabled, and yes, I'll repost today ...
>
> I haven't seen the patch and don't feel like searching. So I say it
> here: please mak sure you add a f
On 11/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Nov 2007 16:35:38 -0800 (PST) Davide Libenzi
> <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 22 Nov 2007, Andrew Morton wrote:
[...]
> > > Last I recall, we removed the API for 2.6.23 because we intended to do a
> > > different interface
[+linux-kernel]
On Nov 26, 2007 9:13 PM, Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> Maybe I missed it. Did someone write a man-pages for revoke(), which
> I assume is heading towards mainline before long?
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
dom.4
mtk, after a report by Daniel Kahn Gilmor
Add 2.6 details for /proc/sys/kernel/random/poolsize.
as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459232.
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to rep
Hi Davide,
Davide Libenzi wrote:
> On Thu, 13 Dec 2007, Michael Kerrisk wrote:
>
>>>> BUG 2:
>>>> The last sentence does not match the implementation.
>>>> (Nor is it consistent with the behavior of POSIX timers.
>>>> And I *think*
from that,
some work has been done to improve the HTML used for the online pages
(http://www.kernel.org/doc/man-pages/online_pages.html ).
Cheers,
Michael
(man-pages maintenance is supported by Google, as a Google engineer 20%
project.)
--
Michael Kerrisk
Maintainer of the Linux man-pages pr
Hi Davide,
On 12/16/07, Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Dec 2007, Michael Kerrisk wrote:
>
> > You snipped my example that demonstrated the problem. Both of the
> > following runs create a timer that expires 10 seconds from "now", but
problem can occur when the return
value wraps passed the maximum value that can be stored
in clockid_t.
Look okay to you folks?
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bu
Gidday
I've released man-pages-2.74.
This release is now available for download at:
http://www.kernel.org/pub/linux/docs/man-pages
or ftp://ftp.kernel.org/pub/linux/docs/man-pages
Changes in this release can be seen at
http://www.kernel.org/doc/man-pages/changelog.html#release_2.74
A su
efore
> > > > the close, which I now do, but costs me a syscall where I wanted to
> > > > spare one :|
> > >
> > > For epoll, a close is when the kernel file* is released (that is, when all
> > > its instances are gone).
> > > We could put a spe
On Jan 19, 2008 2:14 AM, Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> This adds the RUSAGE_THREAD option for the getrusage system call.
> Solaris calls this RUSAGE_LWP and uses the same value (1).
> That name is not a natural one for Linux, but we keep it as an alias.
Hey Roland,
Would you pleas
cause an uncle cannot wait on his nephews.
In some other Unix-like systems, where multiple threads
are implemented as belonging to a single process, thread A
can wait on any processes forked by sibling thread B; you
will have to rewrite any code that makes this
have with my employer, I
> see I have a task that is now over a year old, still unfinished, to
> provide man pages for cpusets to Michael Kerrisk" <[EMAIL PROTECTED]>
Yes, it would be great to have those pages. Is there anything I can
do to assist?
Cheers,
Michael
PS Note my
On 10/26/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Michael wrote:
> > PS Note my new addres for man-apges: [EMAIL PROTECTED]
>
> Noted.
>
> > Is there anything I can do to assist?
>
> Got any spare round tuit's ;)?
I ran out quite some time ago unfortunately.
Cheers,
Michael
-
To unsubscribe
gnals.
Add SEE ALSO reference to sgetmask.2.
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for &#
Amit,
I've taken the page that you sent and made various minor formatting and
wording fixes. I've also added various FIXMEs to the page. Some of these
("FIXME .") are things that I need to check up later. Some others are
questions for which I need input from you, David, or someone else with the
Andrew,
The timerfd() syscall went into 2.6.22. While writing the man page for
this syscall I've found some notable limitations of the interface, and I am
wondering whether you and Linus would consider having this interface fixed
for 2.6.23.
On the one hand, these fixes would be an ABI change, w
ication is
not checking the return from read(), then its 8-byte buffer will not be
filled -- the contents of the last 4 bytes will be undefined, so the u64
value as a whole will be junk.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with
Ray,
> On 7/22/07, Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> > Problem 1
> > -
> >
> > The value returned by read(2)ing from a timerfd file descriptor is
> > the
> > number of timer overruns. In 2.6.22, this value is 4 bytes, limiting
's the other problems with the interface that bother me more
(inability to retrieve previous setting when changing
the timer; inability to retrieve time until next expiration
without changing the current setting).
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3,
e(), timer_settime(), timer_gettime()).
Or (if possible, and even better) timerfd() integrated with POSIX timers.
Then we have a good API for the coming decades. I'm prepared to help
out with patches (for what my help is worth ;-)).
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man
t;
>
>
> I'd have thought that the existing stuff would be near-useless without
> the capabilities which you describe?
Not useless, but certainly less functional than it can/should be
(and with not too much effort on the kernel implementation side).
Cheers,
Michael
--
Mich
the functionality of the existing POSIX
timers API.
> and in terms of kernel code footprint.
Not sure what your concern is here. The total amount of
new code for all of these options is pretty small.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4,
off to an application: that library may want
to modify the timer settings without having to create a
new file descriptor (the app mey not be able to be told about
the new fd). Your argument just doesn't hold, AFAICS.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Section
s is on us to explain why they got this point wrong.
And it is not merely POSIX that did things things in the
way I've described: so did the earlier setitimer()/getitimer().
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page
[Was: Re: [PATCH] Revised timerfd() interface]
> Michael, could you please refresh our memories with a brief,
> from-scratch summary of what the current interface is, followed
> by a summary of what you believe to be the shortcomings to be?
Andrew,
I'll break this up into parts:
1. the existin
y
a timer's settings at the same timer as another thread is
select()ing on it? The first thread can't do this by creating
a new timerfd timer, since it wants to affect the select()
in the other thread?
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3
ld: fd = %d\n", fd);
> if (fcntl (fd, F_GETFD) == 0 || errno != EBADF)
> {
> puts ("file descriptor valid in child");
> return 1;
> }
> return 0;
> }
>
> fd = open ("/proc/self/exe", O_RDONLY | O_CLOEXEC)
stack space.) Architectures with no
memory management unit are excepted: they maintain the
pre-2.6.23 limit.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
h
ed
> whenever the new timer setting expires.
We are going in circles here. I think you are missing my point.
Consider the following
[[
Thread A: calls library function which creates a timerfd file
descriptor.
Thread B: calls select() on the timerfd file descriptor.
Thread A: calls library
ts);
> th->clockid = clockid;
> th->ts = *ts;
> return 0;
> }
>
> Wrap the get/set with a mutex in case you plan to shoot yourself in a
> foot by doing get/set from multiple threads ;)
> So, once again:
>
> - I sincerly doubt the above is common u
Ulrich,
> On 9/5/07, Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> > O_CLOEXEC (Since Linux 2.6.23)
> > Enable the close-on-exec flag for the new file
> > descriptor. This is useful in multithreaded programs
> > since u
1 - 100 of 1513 matches
Mail list logo
