Re: [systemd-devel] [ANNOUNCE] systemd 27

2011/5/20 fykc...@gmail.com : > Hi Lennart, > > It seems we need to include in socket-util.c, to make > build successful. > I've made a patch in attachment. Didn't notice that is already included in socket-util.h, sorr

Re: [systemd-devel] [ANNOUNCE] systemd 27

Hi Lennart, It seems we need to include in socket-util.c, to make build successful. I've made a patch in attachment. 2011/5/20 Lennart Poettering : > Heya! > > http://www.freedesktop.org/software/systemd/systemd-27.tar.bz2 > > Nothing too fancy. But a few new features. > > Kay Sievers (4): >    

Re: [systemd-devel] udev took too long to start

Hi, udev.service doesn't include 'settle' action, it is simplely because udev starting/adding spends some time. Many services depends on udev directly or indirectly, so the boot process is serialized when udev starting. Currently, systemd is deeply integrated with udev, it was not easy to "First

Re: [systemd-devel] [PATCH] util: arg 'nbytes' of loop_read/write should be of type ssize_t

2011/5/3 Kay Sievers : > On Tue, May 3, 2011 at 03:00, fykc...@gmail.com wrote: >> 2011/5/3 Kay Sievers >>> >>> On Mon, May 2, 2011 at 05:18, fykc...@gmail.com wrote: >>> >  loop_read/write will try to fill/read 'nbytes' of caller >>&g

Re: [systemd-devel] [PATCH] util: arg 'nbytes' of loop_read/write should be of type ssize_t

Hi, 2011/5/3 Kay Sievers > > On Mon, May 2, 2011 at 05:18, fykc...@gmail.com wrote: > >  loop_read/write will try to fill/read 'nbytes' of caller supplying buffer. > > This argument is currently of type size_t, which is always true > > for loop quit condit

[systemd-devel] [PATCH] util: arg 'nbytes' of loop_read/write should be of type ssize_t

Hi all, loop_read/write will try to fill/read 'nbytes' of caller supplying buffer. This argument is currently of type size_t, which is always true for loop quit condition "while (nbytes > 0)", hence we change it to type ssize_t here. This also helps to detect passed-in 'nbytes' of value -1 for exa

Re: [systemd-devel] How to implement fsck progress report with systemd and plymouth?

Hi, 2011/4/27 Lennart Poettering : > I would suggest to leave the parsing of the fsck -C output to fsckd, as > well as the integration of multiple of these streams. fsckd would then > only pass one stream of progress bar information to plymouth. The > handling in Plymouth would be very simple: you

Re: [systemd-devel] How to implement fsck progress report with systemd and plymouth?

2011/4/25 Lennart Poettering : > On Fri, 22.04.11 15:04, fykc...@gmail.com (fykc...@gmail.com) wrote: > >> Hi all, >> >> plymouth in Ubuntu 10.04 supports fsck progress report, and also >> provides a chance for user to cancel running fsck. How to implement >> th

[systemd-devel] How to implement fsck progress report with systemd and plymouth?

Hi all, plymouth in Ubuntu 10.04 supports fsck progress report, and also provides a chance for user to cancel running fsck. How to implement this feature with systemd and plymouth? I did some investigation, found: 1. ubuntu patches on_update() of plymouth/src/main.c, it will filter out status mes

Re: [systemd-devel] [PATCH][V3] Fix broken syscall(__NR_fanotify_mark... on o32 mips.

The third version of patch "Fix broken syscall(__NR_fanotify_mark... on o32 mips". Changes since v2: 1. Condition of whether split 64bit argument is now gated by ''defined _MIPS_SIM && _MIPS_SIM == _MIPS_SIM_ABI32". Thank David for pointing it out. -- Regards, - cee1 0001-Fix-broken-syscall

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/21 David Daney : > On 04/20/2011 06:02 PM, fykc...@gmail.com wrote: >> >> 2011/4/21 David Daney: >>>> >>>> Any comment whether this will break non-MIPS 32bit archs, like x86? >>> >>> It would break the MIPS n32 ABI userspace. >>

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/21 Eric Paris : > I am pretty arch stupid, and I have no idea at all if it is related, but > I'm looking at kernel commit 5e844b31c2ace282ab8bea630b63e0212d9532d4 > which wires up the fanotify syscalls for mips.  I see that it used a u64 > for a3 and a4 when these are only going to be 32 val

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/21 David Daney : > On 04/20/2011 11:09 AM, Lennart Poettering wrote: >> >> On Wed, 20.04.11 10:36, David Daney (dda...@caviumnetworks.com) wrote: >> >>> You would have to do something like this (untested): >>> >>> int foo_fanotify_mark(int fanotify_fd, unsigned int flags, u64 mask, >>> int d

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/21 David Daney : >> Any comment whether this will break non-MIPS 32bit archs, like x86? > > It would break the MIPS n32 ABI userspace. > > On MIPS n32 we are still __LP64__, but 64-bit values are passed in a single > register. It isn't a problem. n32 syscall supports 64bit registers, and 64-

Re: [systemd-devel] [PATCH][v2] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

Hi all, The second version of patch "Fix broken syscall(__NR_fanotify_mark... on 32bit mips". Changes since v1: 1. Use __LP64__ to detect whether in a 64bit environment. 2. Some code clean up. Fix-broken-__NR_fanotify_mark.-on-32bit-v2.patch Description: Binary data

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/20 Lennart Poettering : > On Wed, 20.04.11 09:15, fykc...@gmail.com (fykc...@gmail.com) wrote: > >> >> 2011/4/20 Lennart Poettering >> > >> > On Thu, 14.04.11 17:34, fykc...@gmail.com (fykc...@gmail.com) wrote: >> > >> > > diff -

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011/4/20 Lennart Poettering > > On Thu, 14.04.11 17:34, fykc...@gmail.com (fykc...@gmail.com) wrote: > > > diff --git a/src/missing.h b/src/missing.h > > index 35e209f..b367831 100644 > > --- a/src/missing.h > > +++ b/src/missing.h > > @@ -125,7 +12

[systemd-devel] Not start readahead-collect if /.readahead exists

Hi all, /.readahead exists means activated readahead-replay will run. Meanwhile if readahead-collect runs, all replayed blocks will be collected -- size of /.readahead will increase(e.g. in case of services update). -- Regards, - cee1 From 6afc8f53fa026f099d133df75e5326eb1cf7af35 Mon Sep 17 0

[systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

Hi all, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23618562 MIPS ABI enforces that 64bit arguments should be 64bit-aligned, and the third argument of syscall(__NR_fanotify_mark, ...) is 64bit and not 64bit-aligned on 32bit mips platform, thus extra padding is inserted before it. The syscal

Re: [systemd-devel] [lenn...@kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

Hi, 2010/12/24 Lennart Poettering > > Heya, > > just wanted to let everybody know that I reverted the logic in > pam_sytemd which automatically creates a cgroup in the 'cpu' hierarchy > for every user/session, since it makes it impossible to use RT > scheduling from user/session processes then. F

Re: [systemd-devel] Improve boot-time of systemd

2011/3/29 Lennart Poettering : > On Tue, 29.03.11 03:36, fykc...@gmail.com (fykc...@gmail.com) wrote: >> To make boot fast, it seems udev's coldplug do too much jobs -- what I >> expect is only coldplug local block devices and tty in that stage. >> This can save ~2s in

Re: [systemd-devel] Improve boot-time of systemd

Hi Kay, 2011/3/28 Kay Sievers : > On Fri, Mar 18, 2011 at 14:57, Kay Sievers wrote: > > Udev no longer enables udev-settle.service by default now. > basic.target is no longer blocked by it, and udev's coldplug will run > in the background. To make boot fast, it seems udev's coldplug do too much j

Re: [systemd-devel] Improve boot-time of systemd

2011/3/28 Lennart Poettering : > On Sun, 20.03.11 05:28, fykc...@gmail.com (fykc...@gmail.com) wrote: >> Current readahead implementation has some problems: >> 1. It can't separate *real* block read requests from all read >> requests(which includes more blocks read

Re: [systemd-devel] [PATCH v3] Detect page size runtime

The third version if this patch. Changes since v2: 1. page_size() uses assert_se(sysconf(...)) to detect failure of sysconf, abort if sysconf fails. 2011/3/19 Jan Engelhardt : > On Saturday 2011-03-19 07:18, fykc...@gmail.com wrote: > >>> sparc64 would, to name one. >>IA64,

Re: [systemd-devel] Improve boot-time of systemd

2011/3/19 Chen Jie : > 2011/3/18 Kay Sievers : >> >> It's ~0.5 sec faster here with readahead on a SSD. > Each time runs readahead-replay may cause readahead-collect to record > more blocks to read ahead -- size of "/.readahead" never reduces. > > Also I found "/.readahead" recorded files like ".xe

Re: [systemd-devel] [PATCH v2] Detect page size runtime

2011/3/19 Jan Engelhardt : > On Saturday 2011-03-19 03:10, Lennart Poettering wrote: > >>On Fri, 18.03.11 03:44, fykc...@gmail.com (fykc...@gmail.com) wrote: >> >>> Hi all, >>> >>> Systemd hardcode page size as 4096(in macro.h), this is not alway

[systemd-devel] [PATCH] Detect page size runtime

Hi all, Systemd hardcode page size as 4096(in macro.h), this is not always correct: """ Some architectures support multiple machine types with diffenent page sizes, and some machine types even support multiple page sizes themselves. """ This patch tries to detect page size runtime by sysconf(_SC_

Re: [systemd-devel] [Patch v2] Fix systemd-readahead-collect on mips platform

Hi Lennart, This is the second version of patch "Fix systemd-readahead-collect on mips platform". 2011/3/17 Lennart Poettering : >> The patch fix two problems: >> 1. The system call number of __NR_fanotify_* is not corrrect on mips. > > This one definitely makes sense for us to merge. Could you s

Re: [systemd-devel] [Patch] Fix systemd-readahead-collect on mips platform

2011/3/16 Lennart Poettering : > On Wed, 16.03.11 11:46, fykc...@gmail.com (fykc...@gmail.com) wrote: > >> Hi all, >> >> Attachment is the patch fixing broken systemd-readahead-collect on >> mips. The patch is actually fixing the fanotify syscall on mips: >>

[systemd-devel] [Patch] Fix systemd-readahead-collect on mips platform

Hi all, Attachment is the patch fixing broken systemd-readahead-collect on mips. The patch is actually fixing the fanotify syscall on mips: 1. Adjust to correct syscall number. 2. Using directly fanotify syscall instead of "syscall(__NR_FANOTIFY_MARK)", which is broken on the test platform. Test

Re: [systemd-devel] [lenn...@kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

2011/2/14 Andrey Borzenkov > RT is about determinism. You need to ensure that task will be able to > respond in fixed time. If you allow arbitrary, unknown in advance, > number of tasks share the same limited CPU share, you simply kill > determinism. > > Personally I think that RT should be restr

Re: [systemd-devel] [lenn...@kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

untime_us. 2011/2/14 Lennart Poettering > On Fri, 11.02.11 10:30, fykc...@gmail.com (fykc...@gmail.com) wrote: > > > Hi Lennart, Andrey, > > > > Some questions about the discuss: > > 1. Does systemd re-enable sorting user sessions into their own cgroups > in > >

Re: [systemd-devel] [lenn...@kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

Hi Lennart, Andrey, Some questions about the discuss: 1. Does systemd re-enable sorting user sessions into their own cgroups in the 'cpu' hierarchy? 2. AIUI, rtkit is a daemon used for doing RT-related privilege operations. It doesn't spawn RT-threads. Am I right? 3. Does rtkit have related

Re: [systemd-devel] [PATCH] avoid race condition in pick_next_task_fair in kernel/sched_fair.c

Just mention it, Peter wrote a patch( https://groups.google.com/d/msg/linux-kernel-proxy/-eAPuf_OcmI/mD81JdSzxckJ), and it works for me. 2010/12/23 fykc...@gmail.com > Hi all, > > I encountered kernel panic with systemd too, but not sure is related with > this thread. The Call Tr

Re: [systemd-devel] [lenn...@kemper.freedesktop.org: [systemd-commits] src/pam-module.c]

Hi Lennart, 2010/12/24 Lennart Poettering > > > This is related to the issue reported in LWN about JACK+cgroups. Also, > this issue breaks my 4 line bash patch as known from slashdot, AIUI, This is not a kernel problem, and is related with libcgroup . Quo

Re: [systemd-devel] Question about 'vt100-nav' : unknown terminal type

Hi Lennart, Thank you for the reply. Still get one question: what does the comment "Proper handling of /dev/console would be cool" mean? I found exec_spawn(src/execute.c) will call default_term_for_tty: our_env[n_env++] = strdup(default_term_for_tty(tty_path(context))) If I didn't specify TTYPa

Re: [systemd-devel] [PATCH] avoid race condition in pick_next_task_fair in kernel/sched_fair.c

Hi all, I encountered kernel panic with systemd too, but not sure is related with this thread. The Call Trace mentions pick_next_task_fair: http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/DSC00163.JPG It w

[systemd-devel] Question about 'vt100-nav' : unknown terminal type

Hi all, I tried systemd v15 on debian squeeze, and got message "'vt100-nav' : unknown terminal type.". It seems default_term_for_tty(src/util.c) returns 'TERM=vt100-nav' for input arg tty='console'. After forcing default_term_for_tty to return 'TERM=linux', the message goes away. Also I got a war