from:"fykc...@gmail.com"

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

2010-12-23 Thread fykc...@gmail.com

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 warning message "Starting Serial Getty on tty failed.".  Is
that something to do with serial tty? I passed "console=tty" in kernel
cmdline.

Any idea?




-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2010-12-23 Thread fykc...@gmail.com

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
was a debian sequeeze installed a vanilla kernel 2.6.36.2 and systemd (v15
with sysv-compat disabled), running on Fuloong 2f box(
http://www.linux-mips.org/wiki/Fuloong). When start up finished, I pressed a
key, then kernel panic. It was not produceable each time.

config:
http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/config-2.6.36.2
systemd-debs:
http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/debs/
Howto deploy systemd on debian:
http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/README

2010/12/22 Mike Galbraith 

> On Wed, 2010-12-22 at 09:29 +0100, Peter Zijlstra wrote:
> > On Wed, 2010-12-22 at 01:22 +0100, Miklos Vajna wrote:
> > > Please let me know if you need more info.
> >
> > What distro are you using? it looks like systemd is involved and I'm
> > actively avoiding anything using that crap.
>
> Heh, gearing up to hunt a bug it triggers, just doing all I had to do to
> get the thing built and installed blew my box _all up_.  I still have
> smoldering bits lying about a week later.
>
>-Mike
>
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>

-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2010-12-23 Thread fykc...@gmail.com

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 TTYPath in .service, then tty_path will return
"/dev/console", which causes default_term_for_tty always to return
"TERM=vt100-nav".




-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [[email protected]: [systemd-commits] src/pam-module.c]

2010-12-26 Thread fykc...@gmail.com

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
.

Quotes from LWN(lwn.net/Articles/420407):
"""
if a process is run in a control group with no access to realtime
scheduling, that process will not be able to put itself into a realtime
scheduling class regardless of any resource limit settings.

The kernel, by default, grants realtime access to the "root" control group -
the one which contains all processes in the absence of some policy to the
contrary.
"""

"""
If, however, (1) the libcgroup package has been installed, and (2)
that package has been configured to put all user processes into a
default (non-root) group, the situation changes.

The libcgroup default group does not have realtime access, so processes
expecting to be able to run in a realtime scheduling class will be
disappointed.
"""

IMHO, It should be the job of some thing(like systemd) directly play with
cgroup.
It seems systemd doesn't use libcgroup, am I right? Then, It should be fine
if systemd grants realtime access to cgroup for each user session itself.




-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2010-12-26 Thread fykc...@gmail.com

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 [email protected] 

> 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<http://dev.lemote.com/files/upload/people/%7Echenj/systemd-crash/DSC00163.JPG>
>
>
> <http://dev.lemote.com/files/upload/people/%7Echenj/systemd-crash/DSC00163.JPG>It
> was a debian sequeeze installed a vanilla kernel 2.6.36.2 and systemd (v15
> with sysv-compat disabled), running on Fuloong 2f box(
> http://www.linux-mips.org/wiki/Fuloong). When start up finished, I pressed
> a key, then kernel panic. It was not produceable each time.
>
> 
> config:
> http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/config-2.6.36.2<http://dev.lemote.com/files/upload/people/%7Echenj/systemd-crash/config-2.6.36.2>
> systemd-debs:
> http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/debs/<http://dev.lemote.com/files/upload/people/%7Echenj/systemd-crash/debs/>
> Howto deploy systemd on debian:
> http://dev.lemote.com/files/upload/people/~chenj/systemd-crash/README<http://dev.lemote.com/files/upload/people/%7Echenj/systemd-crash/README>
>
>
> 2010/12/22 Mike Galbraith 
>
> On Wed, 2010-12-22 at 09:29 +0100, Peter Zijlstra wrote:
>> > On Wed, 2010-12-22 at 01:22 +0100, Miklos Vajna wrote:
>> > > Please let me know if you need more info.
>> >
>> > What distro are you using? it looks like systemd is involved and I'm
>> > actively avoiding anything using that crap.
>>
>> Heh, gearing up to hunt a bug it triggers, just doing all I had to do to
>> get the thing built and installed blew my box _all up_.  I still have
>> smoldering bits lying about a week later.
>>
>>-Mike
>>
>> ___
>> systemd-devel mailing list
>> [email protected]
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
>
>
> --
> Regards,
>
> - cee1
>
>


-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [[email protected]: [systemd-commits] src/pam-module.c]

2011-02-10 Thread fykc...@gmail.com

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 systemd service file? Does it run at its own
cgroup with controller=cpu? If yes, how does the cgroup receive
rt-bandwidth(period time, run time)?

2011/2/10 Andrey Borzenkov 

> On Tue, Feb 8, 2011 at 3:11 PM, Lennart Poettering
>  wrote:
> > Weird, weird, weird. So, systemd is in the right cgroup with correct
> > settings but still doesn't have the privs to make itself RT. There's
> > something very weird here.
> >
>
> Kernel bug.
>
> commit f44937718ce3b8360f72f6c68c9481712517a867
> Author: Mike Galbraith 
> Date:   Thu Jan 13 04:54:50 2011 +0100
>
>sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure
>
>If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due
> to autogroup
>not allocating rt_runtime.  Free unused/unusable rt_se and rt_rq,
> redirect RT
>tasks to the root task group, and tell __sched_setscheduler() that it's
> ok.
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>

-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [[email protected]: [systemd-commits] src/pam-module.c]

2011-02-13 Thread fykc...@gmail.com

Hi Lennart,
Thanks for the explanation.

IMHO, To re-enable user session 'cpu' sorting:
a) Desktop distributions disable GROUP_RT in the kernel, then no
rt_bandwidth, all RT-apps can be fully administrated under rtkit.

Or b) cpu cgroup controller should default make sub-cgroups share
rt_bandwidth with their parent.
Internally, kernel uses two separate hierarchies for NORMAL and RT
processes, current logic should be changed as: a new cgroup with a cpu
controller will add a new level in 'NORMAL hierarchy', but not touch
'RThierarchy' unless set sched_rt_runtime_us.


2011/2/14 Lennart Poettering 

> On Fri, 11.02.11 10:30, [email protected] ([email protected]) wrote:
>
> > Hi Lennart, Andrey,
> >
> > Some questions about the discuss:
> >   1. Does systemd re-enable sorting user sessions into their own cgroups
> in
> > the 'cpu' hierarchy?
>
> No, we cannot reenable that before the cpu cgroup controller gets fixed.
>
> On current kernels doing this kind of sorting means practically that all
> processes we sort into a 'cpu' cgroup lose their capability to use RT
> scheduling.
>
> I am not aware of any typical daemon we ship that would use RT
> scheduling hence we are keeping the default 'cpu' cgroup sorting for
> system daemons enabled. However user applications are more likely to use
> RT (for example PA does) and hence we have disabled this for sessions
> for now.
>
> >   2. AIUI, rtkit is a daemon used for doing RT-related privilege
> operations.
> > It doesn't spawn RT-threads. Am I right?
>
> It does use RT privs for the implementatin of the canary watchdog.
>
> >   3. Does rtkit have related systemd service file? Does it run at its own
> > cgroup with controller=cpu? If yes, how does the cgroup receive
> > rt-bandwidth(period time, run time)?
>
> rtkit comes with a systemd unit file. In rtkit git this unit file
> ensures that rtkit is explicitly moved into the root "cpu" cgroup so
> that it can make use of RT scheduling -- if you so will rtkit is the one
> exception to what i mentioned above regarding no system daemons using
> RT.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
>



-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [[email protected]: [systemd-commits] src/pam-module.c]

2011-02-14 Thread fykc...@gmail.com

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 restricted to limited number of
> tasks that are known in advance; then it is responsibility of
> administrator to allocate their CPU share according to requirements.
>
> >
> > 2011/2/14 Lennart Poettering 
> >>
> >>
> >> I am not aware of any typical daemon we ship that would use RT
> >> scheduling hence we are keeping the default 'cpu' cgroup sorting for
> >> system daemons enabled. However user applications are more likely to use
> >> RT (for example PA does) and hence we have disabled this for sessions
> >> for now.
> >>
>
> and for reasons outlined above I think that either PA should not
> require RT to run, or we need dedicated system wide PA daemon that can
> be made RT :)
>
Agree in this sense. RT can be seen as 'hardcode' some computing resource
to simulate dedicated hardware, in other words, virtual dsp, should reside
at system scope.




-- 
Regards,

- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-16 Thread fykc...@gmail.com

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 platform:
* CPU: loongson 2f (mips-compatible)
* Kernel: 2.6.38 with fanotify enabled, 64bit, little endian
* Userland: o32 ABI.


BTW, I enabled systemd-readahead-collect.service,
systemd-readahead-replay.service, they were both in default.target. I
also link systemd-readahead-done.service to default.target, is that
correct?
It seems these services exit quickly, and wasn't observed a boot time
speed-up. The size of /.readahead is around 30K.
Any idea?



--
Regards,
- cee1


0001-Fix-broken-systemd-readahead-collect-on-mips.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-16 Thread fykc...@gmail.com

2011/3/16 Lennart Poettering :
> On Wed, 16.03.11 11:46, [email protected] ([email protected]) wrote:
>
>> 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.
>
> Hmm, what precisely is broken? the syscall() implementation in your
> glibc? If so I'd very much prefer if glibc is fixed instead. We
> generally prefer fixing bugs where they are instead of taping over them
> in other software.
The patch fix two problems:
1. The system call number of __NR_fanotify_* is not corrrect on mips.
2. "syscall(__NR_FANOTIFY_MARK, ...)" doesn't work, I guess it was the
problem of eglibc(see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618562).

P.S. If libc could be shipped with linux kernel( just as
http://lwn.net/Articles/417647/ said), things will be easier in this
case.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-16 Thread fykc...@gmail.com

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 split this
> one off and prep a whitespace clean patch for it? (We actually have a
> git hook that ensures that patches are whitespace clean. It is enabled
> when you run autogen.sh. When I tried to merge your earlier patch today
> I couldn't do so, since your patch was not whitespace clean.)
>
> I you prep me a patch for this part I'll merge it right-away.
>
> BTW, no need to include config.h from the C sources. We do so
> automatically for all sources via gcc's -include switch on the command
> line.
Changes since v1:
1. Split "system call number fix" off.
2. Trailing Whitespace clean up.
3. Don't include config.h in missing.h (it will be done automatically)



-- 
Regards,
- cee1


0001-Fix-broken-systemd-readahead-collect-on-mips.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-17 Thread fykc...@gmail.com

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_PAGESIZE),
and uses 4096 as a failsafe value. Note we need memset vec to zero
before call mincore(src/readahead-collect.c, 129) -- if the pagesize
is not correct, we may randomly record wider range or more ranges to
readahead.



-- 
Regards,
- cee1


0001-Detect-page-size-runtime.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-18 Thread fykc...@gmail.com

2011/3/19 Jan Engelhardt :
> On Saturday 2011-03-19 03:10, Lennart Poettering wrote:
>
>>On Fri, 18.03.11 03:44, [email protected] ([email protected]) wrote:
>>
>>> 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_PAGESIZE),
>>> and uses 4096 as a failsafe value. Note we need memset vec to zero
>>> before call mincore(src/readahead-collect.c, 129) -- if the pagesize
>>> is not correct, we may randomly record wider range or more ranges to
>>> readahead.
>>
>>Hmm, interesting. Which architecture are you using that has a page size
>>!= 4K?
>
> sparc64 would, to name one.
IA64, sparc64, powerpc, and mips, they can configure different page
size(e.g. range from 4K - 32K) at kernel config time.

Changes since v1:
1. Rename get_pagesize() to page_size(), fix C99 violation, and move
PAGE_ALIGN and page_size() to util.h and util.c.
2. page_size() now use static tls variable , it will call sysconf only
once for each thread.
3. Remove page size related stuff from readahead-*.c/h.

Note: I still keep a warning of sysconf call failure in page_size(),
this may help to indicate broken sysconf implementation on some
platform. (IMHO, sysconf(_SC_PAGESIZE) should never fail.)
Any idea?



-- 
Regards,
- cee1


0001-Detect-page-size-runtime.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-19 Thread fykc...@gmail.com

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 ".xession-errors" which
> is written only, thus should not be read ahead.
>
> Maybe adjust readahead-collect-done.timer to 5s will help.
>
Current readahead implementation has some problems:
1. It can't separate *real* block read requests from all read
requests(which includes more blocks read by the kernel's readahead
logic)
2. It just gives advices for how to do kernel's readahead, causes the
first read of a fille to spend more time.

I revisited "Booting Linux in five seconds" article[1],  AIUI, they
did readahead in a different way:
1. They determine "which blocks need to read ahead" by a patch against kernel.
2. They do read ahead(aka replay) by reading each block with the
"idle" I/O scheduler.



Regards,
cee1
---
[1] http://lwn.net/Articles/299483/ Intel made five seconds boot: 1s
for kernel, 1s for early boot, 1s for X and 2s for desktop
environment.
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-21 Thread fykc...@gmail.com

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, [email protected] wrote:
>
>>> sparc64 would, to name one.
>>IA64, sparc64, powerpc, and mips, they can configure different page
>>size(e.g. range from 4K - 32K) at kernel config time.
>
> The sparc64 kernel offers 8K and 64K.
>
Got it thanks.



-- 
Regards,
- cee1


0001-Detect-page-size-runtime.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-28 Thread fykc...@gmail.com

2011/3/28 Lennart Poettering :
> On Sun, 20.03.11 05:28, [email protected] ([email protected]) 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 by the kernel's readahead
>> logic)
>
> Shouldn't make a big difference, since on replay we turn off additional
> kernel-side readahead.
>
> However, it is true that the file will only ever increase, never
> decrease in size.
For collect, it can't filter out:
1. Kernel-side readahead, whether the readahead is initiated by
kernel(when no /.readhead data), or the replay process.
2. Written blocks of files(opened as "r+", "w+", "a"). The written
blocks resides at memory when boot time.

IMHO, the kernel lacks some APIs to notify each *real* read requests.
e.g, It can be done by tracking each read syscall (mmap seems not easy
to handle, though).

>
>> 2. It just gives advices for how to do kernel's readahead, causes the
>> first read of a fille to spend more time.
>
> Hmm?
posix_fadvise(...) may make each read do more readahead(more than the
kernel guess way), thus spend more time. e.g.
* When no replay, someone reads A part of file X --> do some job -->
reads B part of file X.
* When replay, both A and B parts of file X are read in one time, thus
more I/O usage. Other services may spend more time waiting for
I/O.(This can be observed from bootchart diagram)

BTW, does posix_fadvise apply globally or just for the process which calls it?

>
> We do that too. We use "idle" on SSD, and "realtime" on HDD.
Why "realtime" on HDD?

BTW, According to test, the "idle" is not really *idle*, see the attachment.
That means 'replay' will always impact other one's I/O. For 'replay'
in idle I/O class on HDD, other one's I/O performance will reduce by
half, according to the test.



-- 
Regards,
- cee1
<>___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-28 Thread fykc...@gmail.com

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 jobs -- what I
expect is only coldplug local block devices and tty in that stage.
This can save ~2s in my boot test.

Is it possible to support .device unit files?



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-03-29 Thread fykc...@gmail.com

2011/3/29 Lennart Poettering :
> On Tue, 29.03.11 03:36, [email protected] ([email protected]) 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 my boot test.
>>
>> Is it possible to support .device unit files?
>
> Hmm?
>
> Note sure I understand the question, but for a .device unit to show up
> in systemd it must be tagged "systemd" in udev, which only can happen
> when the device was triggered after udev is started.

I've already known that currently systemd can only add .device units
from udev. My question was "Is it suitable for systemd to add supports
of loading .device units from .device unit files in
/lib/systemd/system ?"

What I expect is something like:
My_machine.target.wants/dev-sda1.device 
My_machine.target.wants/dev-sda2.device
...
My_machine.target.wants/dev-tty1.device

-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [[email protected]: [systemd-commits] src/pam-module.c]

2011-03-30 Thread fykc...@gmail.com

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. For a longer explanation
> see the patch I commited (attachment).
>
Just mention it, this also enables autogroup for processes in each
user session. The new autogroup feature will not work if a task has
already attached with a CPU controller.

See kernel/sched_autogroup.c, function task_wants_autogroup.
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-14 Thread fykc...@gmail.com

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 syscall function doesn't know the prototype of
fanotify_mark, so the padding will be passed into kernel as valid argument.



-- 
Regards,

- cee1
From 35cc334cd9254638901b5316bdbffb208f572e73 Mon Sep 17 00:00:00 2001
From: cee1 
Date: Thu, 14 Apr 2011 10:28:42 +0800
Subject: [PATCH 1/2] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

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 syscall function doesn't know the prototype of
fanotify_mark, so the padding will be passed into kernel as valid
argument.

The same problem also exists on powerpc and arm.
---
 src/missing.h |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/missing.h b/src/missing.h
index 35e209f..b367831 100644
--- a/src/missing.h
+++ b/src/missing.h
@@ -125,7 +125,12 @@ static inline int fanotify_init(unsigned int flags, unsigned int event_f_flags)
 
 static inline int fanotify_mark(int fanotify_fd, unsigned int flags, uint64_t mask,
 int dfd, const char *pathname) {
-return syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, dfd, pathname);
+if (sizeof(void *) == 4)
+return syscall(__NR_fanotify_mark, fanotify_fd, flags,
+   *((uint32_t *) &mask), *((uint32_t *) &mask + 1),
+   dfd, pathname);
+else /* 64bit */
+return syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, dfd, pathname);
 }
 
 #ifndef BTRFS_IOCTL_MAGIC
-- 
1.7.4.1

___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-14 Thread fykc...@gmail.com

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 00:00:00 2001
From: cee1 
Date: Thu, 14 Apr 2011 10:54:37 +0800
Subject: [PATCH 2/2] Not start readahead-collect if /.readahead exists

/.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).
---
 units/systemd-readahead-collect.service.in |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/units/systemd-readahead-collect.service.in b/units/systemd-readahead-collect.service.in
index 1a66f9f..b3e3c27 100644
--- a/units/systemd-readahead-collect.service.in
+++ b/units/systemd-readahead-collect.service.in
@@ -11,6 +11,7 @@ DefaultDependencies=no
 Wants=systemd-readahead-done.timer
 Conflicts=shutdown.target
 Before=sysinit.target shutdown.target
+ConditionPathExists=!/.readahead
 
 [Service]
 Type=notify
-- 
1.7.4.1

___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-19 Thread fykc...@gmail.com

2011/4/20 Lennart Poettering 
>
> On Thu, 14.04.11 17:34, [email protected] ([email protected]) 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 +125,12 @@ static inline int fanotify_init(unsigned int flags, 
> > unsigned int event_f_flags)
> >
> >  static inline int fanotify_mark(int fanotify_fd, unsigned int flags, 
> > uint64_t mask,
> >                                  int dfd, const char *pathname) {
> > -        return syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, dfd, 
> > pathname);
> > +        if (sizeof(void *) == 4)
> > +                return syscall(__NR_fanotify_mark, fanotify_fd, flags,
> > +                               *((uint32_t *) &mask), *((uint32_t *) &mask 
> > + 1),
> > +                               dfd, pathname);
> > +        else /* 64bit */
> > +                return syscall(__NR_fanotify_mark, fanotify_fd, flags, 
> > mask, dfd, pathname);
> >  }
> >
> >  #ifndef BTRFS_IOCTL_MAGIC
>
> Hmm, wouldn't this break x86-32?
It works fine on my asus laptop with a 32bit CPU Pentium-M.

We pass two 32bit arguments instead of one 64bit argument. syscall()
doesn't know the prototype, I guess it will only fetch 9 native-width
arguments(1 syscall number + 8 parameters) from the stack. Aurelien,
am I right?

>
> Also, I'd very much prefer if this could be done with compile time
> checks instead of "if". i.e.
>
> #ifdef __mips__
Actually it's not only related to mips, but also to all arch that
force 64-aligned for 64bit argument (Aurelien said this can also be
reproduced on powerpc and arm). So what I want is:
#if PTR_BYTES == 4


I tried to find some macro like PTR_BYTES or PTR_SIZE, but failed. Is
such macro available?

BTW, I guess It's suggested caller should split 64bit arguments for syscall().



--
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-19 Thread fykc...@gmail.com

2011/4/20 Lennart Poettering :
> On Wed, 20.04.11 09:15, [email protected] ([email protected]) wrote:
>
>>
>> 2011/4/20 Lennart Poettering 
>> >
>> > On Thu, 14.04.11 17:34, [email protected] ([email protected]) 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 +125,12 @@ static inline int fanotify_init(unsigned int flags, 
>> > > unsigned int event_f_flags)
>> > >
>> > >  static inline int fanotify_mark(int fanotify_fd, unsigned int flags, 
>> > > uint64_t mask,
>> > >                                  int dfd, const char *pathname) {
>> > > -        return syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, 
>> > > dfd, pathname);
>> > > +        if (sizeof(void *) == 4)
>> > > +                return syscall(__NR_fanotify_mark, fanotify_fd, flags,
>> > > +                               *((uint32_t *) &mask), *((uint32_t *) 
>> > > &mask + 1),
>> > > +                               dfd, pathname);
>> > > +        else /* 64bit */
>> > > +                return syscall(__NR_fanotify_mark, fanotify_fd, flags, 
>> > > mask, dfd, pathname);
>> > >  }
>> > >
>> > >  #ifndef BTRFS_IOCTL_MAGIC
>> >
>> > Hmm, wouldn't this break x86-32?
>> It works fine on my asus laptop with a 32bit CPU Pentium-M.
>>
>> We pass two 32bit arguments instead of one 64bit argument. syscall()
>> doesn't know the prototype, I guess it will only fetch 9 native-width
>> arguments(1 syscall number + 8 parameters) from the stack.
Think it again, I find the above description isn't correct. I guess
the syscall() works like following:
1. syscall() do indirect system call.
2. kernel system call entry handler fetch 8 arguments from some
registers + user stack.

Note, the same system call can have 32bit and 64bit varieties. kernel
will fetch arguments properly. e.g. all <32bit arguments are promoted
to 32bit arguments, according to some arch ABI, kernel system call
entry handler of 32bit variety fetches 8 32bit arguments, and then
dispatches it to specific system call handler.

In this example, in case of 64bit mips kernel + 32bit userland(o32 ABI):
1. syscall(__NR_fanotify_mark, fanotify_fd, flags, mask_low,
mask_high, dfd, pathname)
2. kernel fetches 4 32bit arguments from register a0-a3, and 4 32bit
arguments from user stack. see
http://lxr.linux.no/linux+v2.6.38/arch/mips/kernel/scall64-o32.S.
3. Process indirect syscall (sys32_syscall), just do a shift, redirect
to sys_32_fanotify_mark.
4. In sys_32_fanotify_mark, it merge_64(mask_low, merge_high), and
calls sys_fanotify_mark. see
http://lxr.linux.no/linux+v2.6.38/arch/mips/kernel/linux32.c#L346

>
> Hmm, I am not sure I understand this? How is it possible that both ways
> work on x86? There must be quite a difference between passing 6 or 7
> arguments to syscall.
>
> Or are you suggesting that the current invocation is broken even on x86,
> just doesn't become visible since only the lower 32 bit of "mask" are
> used?
>
>> > Also, I'd very much prefer if this could be done with compile time
>> > checks instead of "if". i.e.
>> >
>> > #ifdef __mips__
>> Actually it's not only related to mips, but also to all arch that
>> force 64-aligned for 64bit argument (Aurelien said this can also be
>> reproduced on powerpc and arm). So what I want is:
>> #if PTR_BYTES == 4
>> 
>>
>> I tried to find some macro like PTR_BYTES or PTR_SIZE, but failed. Is
>> such macro available?
>
> I think "#ifndef __LP64__" does what you want?
Got it, thanks.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

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
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

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-bit
values should be passed in a single register. see
http://lxr.linux.no/linux+v2.6.38/arch/mips/kernel/scall64-n32.S#L426
(calls sys_fanotify_mark instead of sys_32_fanotify_mark,
sys_fanotify_mark won't merge_64(mask_low, merge_high))



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

2011/4/21 David Daney :
> On 04/20/2011 11:09 AM, Lennart Poettering wrote:
>>
>> On Wed, 20.04.11 10:36, David Daney ([email protected]) wrote:
>>
>>> You would have to do something like this (untested):
>>>
>>> int foo_fanotify_mark(int fanotify_fd, unsigned int flags, u64 mask,
>>> int dfd, const char  __user * pathname)
>>> {
>>>        u32 mask_low = (u32)mask;
>>>        u32 mask_high = (u32)(mask>>  32);
>>>
>>>        return syscall(4337, fanotify_fd, flags, mask_low, mask_high, dfd,
>>> pathname);
>>>
>>> }
>>>
>>> The order of mask_low, mask_high in the syscall argument list
>>> depends on the endianness.  Figuring out the correct order is left
>>> as an exercise for the reader.
>>
>> That's basically the same patch as this one, right?
>>
>>
>> http://lists.freedesktop.org/archives/systemd-devel/attachments/20110420/be2d393b/attachment.obj
>>
>
> It looks like it might do the same thing.  Someone should try it on an o32
> MIPS userland running on a mips64 kernel.
I tested it on o32 userland + n64 kernel. The patch works.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

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 values.  Does that
> matter?  I also see that some prototype such as sys32_readahead()
> explicitly added a pad into the 32 helper.  Should we be doing that?
This will break the direct system call way.

> I also notice that the naming of arguments seems wrong (although it
> shouldn't matter)
>
> SYSCALL_DEFINE6(32_fanotify_mark, int, fanotify_fd, unsigned int, flags,
>                u64, a3, u64, a4, int, dfd, const char  __user *, pathname)
IMHO, rearrange the order of arguments can do the trick(But API
changes). e.g. exchange positions of 'mark' and 'flags'. mark will in
a 64-aligned position in case of indirect syscall. In direct syscall,
libc can take care of it.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

2011/4/21 David Daney :
> On 04/20/2011 06:02 PM, [email protected] 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.
>>>
>>> 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-bit
>> values should be passed in a single register. see
>> http://lxr.linux.no/linux+v2.6.38/arch/mips/kernel/scall64-n32.S#L426
>> (calls sys_fanotify_mark instead of sys_32_fanotify_mark,
>> sys_fanotify_mark won't merge_64(mask_low, merge_high))
>>
>
> What are you talking about?
Sorry, misunderstand it, on "n32", __LP64__ won't be defined, right?



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-20 Thread fykc...@gmail.com

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-__NR_fanotify_mark.-on-o32-mips.patch
Description: Binary data
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-22 Thread fykc...@gmail.com

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 message from fsck, if message starts with "fsck:".
2. ubuntu provides a plymouth theme -- ubuntu-logo, which is of type
script, and has some fsck related stuff.

I guess we need:
1. Support "detailed status report" in plymouth, e.g. colon separated fields.
2. Hook fsck detailed message to each theme in plymouth ?
3. Emit fsck message to plymouth in systemd-fsck.
4. How to support user-cancellable fsck?

Any idea?



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-24 Thread fykc...@gmail.com

2011/4/25 Lennart Poettering :
> On Fri, 22.04.11 15:04, [email protected] ([email protected]) 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
>> this feature with systemd and plymouth?
>
> It's actually a really hard problem. For example, what do you do when
> you have multiple disks which are fsck'ed in parallel or serial? You'd
> then have to integrate their individual progress bars somehow.
It seems ubuntu's implementation uses limited 'progress bars'. I guess
any more fsck progress reports will no be displayed.

>
>> I did some investigation, found:
>> 1. ubuntu patches on_update() of plymouth/src/main.c, it will filter
>> out status message from fsck, if message starts with "fsck:".
>> 2. ubuntu provides a plymouth theme -- ubuntu-logo, which is of type
>> script, and has some fsck related stuff.
>>
>> I guess we need:
>> 1. Support "detailed status report" in plymouth, e.g. colon separated
>> fields.
>> 2. Hook fsck detailed message to each theme in plymouth ?
>> 3. Emit fsck message to plymouth in systemd-fsck.
>> 4. How to support user-cancellable fsck?
>
>> Any idea?
>
> Here's what I'd suggest: We already have systemd-fsck, which we could
> beef up slightly to pass progress data to a tiny AF_UNIX socket
> activated service (let's call it fsckd) which integrates the data from
> multiple instances of systemd-fsck and sends it off to plymouth. And if
> a cancel request is received from plymouth it would send off SIGINT to
> the the systemd-fsck instances which it got data from.
>
> This could be done in a relative easy and elegant way by having
> systemd-fsck just pass the socket it created as channel to fsckd as -C
> fd to to fsck. That way only fsckd would have to parse the progress data
> from fsck, and it would talk directly to fsck which would allow fsckd to
> figure out the fsck PID via SCM_CREDENTIALS, so that fsckd would know
> what to kill.
Good idea. Thanks.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-04-27 Thread fykc...@gmail.com

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'd just add a single
> request which gets a percentage. You show the bar on the first of those
> you get, you hide the bar if the percentage you get is >= 100. And all
> the dirty stuff would stay in fsckd. fsckd would probably just take the
> minimum of the most recent percentage data from all its clients and pass
> that on to plymouth.
I'm currently trying to do similar, but:
1. Parsing "fsck -C" output in systemd-fsck. All instances of
systemd-fsck send this progress status to plymouth, and let theme
decide how to display them on screen.
2. If user press e.g. 'C' to cancel a certain fsck job, then plymouth
will send SIGINT to corresponding instance of systemd-fsck.

This saves fsckd in "plymouth <-> fsckd <-> n * systemd-fsck".



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-01 Thread fykc...@gmail.com

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 example.




-- 
Regards,

- cee1
From 54e7ea82ca0051660927d2c4a6c1fdef7fd497a4 Mon Sep 17 00:00:00 2001
From: cee1 
Date: Mon, 2 May 2011 10:52:11 +0800
Subject: [PATCH] util: arg 'nbytes' of loop_read/write should be of type
 ssize_t

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 example.
---
 src/util.c |4 ++--
 src/util.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/util.c b/src/util.c
index f0051ee..252da55 100644
--- a/src/util.c
+++ b/src/util.c
@@ -2623,7 +2623,7 @@ int close_pipe(int p[]) {
 return a < 0 ? a : b;
 }
 
-ssize_t loop_read(int fd, void *buf, size_t nbytes, bool do_poll) {
+ssize_t loop_read(int fd, void *buf, ssize_t nbytes, bool do_poll) {
 uint8_t *p;
 ssize_t n = 0;
 
@@ -2671,7 +2671,7 @@ ssize_t loop_read(int fd, void *buf, size_t nbytes, bool do_poll) {
 return n;
 }
 
-ssize_t loop_write(int fd, const void *buf, size_t nbytes, bool do_poll) {
+ssize_t loop_write(int fd, const void *buf, ssize_t nbytes, bool do_poll) {
 const uint8_t *p;
 ssize_t n = 0;
 
diff --git a/src/util.h b/src/util.h
index 5f6325b..f0b3d70 100644
--- a/src/util.h
+++ b/src/util.h
@@ -327,8 +327,8 @@ int sigaction_many(const struct sigaction *sa, ...);
 
 int close_pipe(int p[]);
 
-ssize_t loop_read(int fd, void *buf, size_t nbytes, bool do_poll);
-ssize_t loop_write(int fd, const void *buf, size_t nbytes, bool do_poll);
+ssize_t loop_read(int fd, void *buf, ssize_t nbytes, bool do_poll);
+ssize_t loop_write(int fd, const void *buf, ssize_t nbytes, bool do_poll);
 
 int path_is_mount_point(const char *path);
 
-- 
1.7.5.rc1

___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-02 Thread fykc...@gmail.com

Hi,

2011/5/3 Kay Sievers 
>
> On Mon, May 2, 2011 at 05:18, [email protected]  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 condition "while (nbytes > 0)", hence we change it to
> > type ssize_t here.
>
> Where would that be useful? It's the size of the buffer supplied to
> the function, just like read() itself has.
Note "while(nbytes > 0)" is equal to "while(true)", if the supplying
buffer is smaller than contents of a file, read syscall may overwrite
memory after 'buf', or return with errno EFAULT.

>
> > This also helps to detect passed-in 'nbytes' of value -1
> > for example.
>
> Detect what that way, a negative sizeof()?
This 'nbytes' maybe a variable, and happens to be -1? Also, it is
symmetric if the range of return value(number of bytes read) is equal
to the range of 'nbytes'.




--
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-02 Thread fykc...@gmail.com

2011/5/3 Kay Sievers :
> On Tue, May 3, 2011 at 03:00, [email protected]  wrote:
>> 2011/5/3 Kay Sievers 
>>>
>>> On Mon, May 2, 2011 at 05:18, [email protected]  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 condition "while (nbytes > 0)", hence we change it to
>>> > type ssize_t here.
>>>
>>> Where would that be useful? It's the size of the buffer supplied to
>>> the function, just like read() itself has.
>> Note "while(nbytes > 0)" is equal to "while(true)"
>
> Why? nbytes can be zero, and then it's false. It's counting down with
> every read().
Sorry, I didn't notice nbytes will never  be smaller  than
k(http://cgit.freedesktop.org/systemd/tree/src/util.c#n2667).

Thank you and sorry for noise here.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-18 Thread fykc...@gmail.com

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 do coldplug stage which is not using udev, and then do hotplug
later through udev".


2011/5/18 microcai 
>
> OK, here is my problem:
>
>
> udev and systemd are from systemd overlay.
>
> udev is udev-168-r1
> systemd is systemd-26
>
> All compiled with CFLAGS="-Os -march=native"
>
> systemd-analyze plot have problem generationg SVG file, so I change the
> code to make a PDF.
>
>
> Will anyone please lookat my boot analyze PDF?
>
> Why udev took so long to settle down ?!
>
> Thanks.
>
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



--
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-19 Thread 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.

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):
>      binfmt, modules-load, sysctl, tmpfiles: read /usr/local/lib and where 
> appropriate /lib directories
>      binfmt, modules-load, sysctl, tmpfiles: add missing 
> ConditionDirectoryNotEmpty=
>      sysctl: correct /usr/local/lib path
>      update TODO
>
> Koen Kooi (2):
>      build-sys: Angstrom support
>      systemd-analyze: print hostname, kernelversion and arch at the top of 
> the plot
>
> Lennart Poettering (21):
>      units: enable automount units only if the kernel supports them
>      update TODO
>      update TODO
>      vconsole: use open_terminal() instead of open()
>      unit: make ignoring in snapshots a per unit property, instead of a per 
> unit type property
>      user-sessions: ignore EROFS when unlinking /etc/nologin if the file 
> doesn't exist anyway
>      hostnamed: SetPrettyHostname() should check PK action 
> org.freedesktop.hostname1.set-static-hostname
>      pam: downgrade a few log msgs
>      update TODO
>      hostnamed: check that nss-myhostname is installed
>      README: document relation to nss-myhostname
>      socket: add POSIX mqueue support
>      socket: use 666 socket mode by default since neither fifos, nor sockets, 
> nor mqueues need to be executable
>      exec: hangup/reset/deallocate VTs in gettys
>      socket: expose IP_TRANSPARENT
>      exec: expose tty reset options in dbus introspection data
>      git: add .mailmap
>      socket: expose SO_BROADCAST
>      util: use open_terminal() in chvt() too
>      update TODO
>      build-sys: prepare new release 27
>
> Ludwig Nussel (1):
>      sysctl: apply /etc/sysctl.conf last
>
> Michael Olbrich (1):
>      build-sys: create dbussystemservicedir
>
> Miklos Vajna (1):
>      units: Enable plymouth for Frugalware
>
> Paul Menzel (1):
>      util: include `stdarg.h`
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> ___
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Regards,
- cee1
From da4758c70c137a40a295cff9740018f8139abf13 Mon Sep 17 00:00:00 2001
From: cee1 
Date: Fri, 20 May 2011 11:35:51 +0800
Subject: [PATCH] socket-util.c: include netinet/in.h

---
 src/socket-util.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/socket-util.c b/src/socket-util.c
index e2e8988..6468766 100644
--- a/src/socket-util.c
+++ b/src/socket-util.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "macro.h"
 #include "util.h"
-- 
1.7.5.rc1

___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2011-05-19 Thread fykc...@gmail.com

2011/5/20 [email protected] :
> 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, sorry.



-- 
Regards,
- cee1
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

38 matches

Mail list logo