Re: [systemd-devel] Improving module loading

2014-12-23 Thread Hoyer, Marko (ADITG/SW2)
Hi Greg,

thx a lot for the feedback and hints. You asked for lots of numbers, I tried to 
add some I have available here at the moment. Find them inline. I'm 
additionally interested in some more details of some of the ideas you outlined. 
Would be nice if you could go some more into details at certain points. I added 
some questions inline as well.

 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Sunday, December 21, 2014 6:47 PM
 To: Hoyer, Marko (ADITG/SW2)
 Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] Improving module loading
 
 On Sun, Dec 21, 2014 at 12:31:30PM +, Hoyer, Marko (ADITG/SW2)
 wrote:
   If you have control over your kernel, why not just build the
 modules
   into the kernel, then all of this isn't an issue at all and there
 is
   no overhead of module loading?
 
  It is a questions of kernel image size and startup performance.
  - We are somehow limited in terms of size from where we are loading
 the kernel.
 
 What do you mean by this?  What is limiting this?  What is your limit?
 How large are these kernel modules that you are having a hard time to
 build into your kernel image?
- As far as I remember, we have special fastboot aware partitions on the emmc 
that are available very fast. But those are very limited in size. But with this 
point I'm pretty much not sure. This is something I got told.

- targeted kernel size: 2-3MB packed

- Kernel modules:
- we have heavy graphics drivers (~800kb, stripped), they are needed 
half the way at startup
- video processing unit drivers (don't know the size), they are needed 
half the way at startup
- wireless  bluetooth, they are needed very late
- usb subsystem, conventionally needed very late (but this finally 
depends on the concrete product)
- hot plug mass storage handling, conventionally needed very late (but 
this finally depends on the concrete product)
- audio driver, in most of our products needed very late
- some drivers for INC communication (partly needed very early - we 
compiled in them, partly needed later - we have them as module)

All in all I'd guess we are getting twice the size if we would compile in all 
the stuff.

 
  - Loading the image is a kind of monolithic block in terms of time
  where you can hardly do things in parallel
 
 How long does loading a tiny kernel image actually take?

I don't know exact numbers, sorry. I guess something between 50-200ms plus time 
for unpacking. But this loading and unpacking job is important since it is 
located directly on the critical path.

 
  - We are strongly following the idea from Umut (loading things not
  before they are actually needed) to get up early services very early
  (e.g. rendering a camera on a display in less than 2secs after power
  on)
 
 Ah, IVI, you all have some really strange hardware configurations :(

Yes IVI. Since we are developing our hardware as well as our software 
(different department), I'm interested in getting more infos about what is 
strange about IVI hardware configuration in general. Maybe we can improve 
things to a certain extent. Could you go more into details?

 
 There is no reason you have to do a cold reset to get your boot times
 down, there is the fun resume from a system image solution that
 others have done that can get that camera up and displayed in
 milliseconds.
 

I'm interested in this point.
- Are you talking about Save To RAM, Save to Disk, or a hybrid combination 
of both?
- Or do you have something completely different in mind?

I personally thought about such a solution as well. I'm by now not fully 
convinced since we have really hard timing requirements (partly motivated by 
law). So I see two different principal ways for a resume solution:
- either the resume solution is robust enough to guarantee to come up properly 
every boot up
- achieved for instance by a static system image that brings the system 
into a static state very fast, from which on a kind of conventional boot is 
going on then ...
- or the boot up after an actual cold reset is fast enough to at least 
guarantee the really important timing requirements in case the resume is not 
coming up properly

  - Some modules do time / CPU consuming things in init(), which would
  delay the entry time into userspace
 
 Then fix them, that's the best thing about Linux, you have the source
 to not accept problems like this!  And no module should do expensive
 things in init(), we have been fixing issues like that for a while now.
 

This would be properly the cleanest solution. In a long term perspective we are 
of course going this way and we are trying to get suppliers to go this way with 
us as well. But finally, we have to bring up now products at a fixed date. So 
it sometimes is easier, and more stable to work around suboptimal things.

For instance:
- refactoring a driver that is doing lots of CPU 

Re: [systemd-devel] Improving module loading

2014-12-23 Thread Hoyer, Marko (ADITG/SW2)
 -Original Message-
 From: Lucas De Marchi [mailto:lucas.de.mar...@gmail.com]
 Sent: Monday, December 22, 2014 7:00 PM
 To: Lennart Poettering
 Cc: Hoyer, Marko (ADITG/SW2); systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] Improving module loading
 
 On Mon, Dec 22, 2014 at 1:04 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Sat, 20.12.14 10:45, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-
 jv.com) wrote:
 
  I had such a discussion earlier with some of the systemd guys. My
  intention was to introduce an additional unit for module loading for
  exactly the reason you mentioned. The following (reasonable) outcome
  was:
 
  - It is dangerous to load kernel modules from PID 1 since module
loading can get stuck
 
  - Since modules are actually loaded with the thread that calls the
syscall, systemd would need additional threads
 
  - Multi Threading is not really aimed in systemd for stability
  reasons
 
  The probably safest way to do what you intended is to use an
  additional process to load your modules, which could be easily done
  by using ExecStartPre= in a service file. We are doing it exactly
  this way not with kmod but with a tool that loads modules in
  parallel.
 
  I'd be willing to merge a good patch that beefs up
  systemd-modules-load to load the specified modules in parallel, with
  one thread for each.
 
  We already have a very limited number of threaded bits in systemd,
 and
  I figure out would be OK to do that for this too.
 
  Please keep the threading minimal though, i.e. one kmod context per
  thread, so that we need no synchronization and no locking. One thread
  per module, i.e. no worker thread logic with thread reusing. also,
  please set a thred name, so that hanging module loading only hang one
  specific thread and the backtrace shows which module is at fault.
 
 I'm skeptical you would get any speed up for that. I think it would be
 better to have some numbers shared before merging such a thing.
 

As I already outlined in my answer to Greg, the parallel loading was not our 
main motivation for inventing something new. We found that for some of our 
modules parallel loading gained us benefit, so we integrated this feature. 
Since we are not using udevd during startup at all, most of our modules are 
loaded manually. I've no idea how things are distributed between 
systemd-modules-load and udevd in conventional Linux desktop or server systems. 
If only a hand full of modules are actually loaded using systemd-modules-load, 
it is probably not worth optimizing at this end.

Has someone concrete numbers how many modules are loaded by hand using 
systemd-modules-load in a conventional system?

 If you have 1 context per module/thread you will need to initialize
 each context which is really the most expensive part in userspace,
 particularly if finit_module() is being used (which you should unless
 you have restrictions on the physical size taken by the modules). Bare
 in mind the udev logic has only 1 context, so the initialization is
 amortized among the multiple module load calls.
 

This does not really meet my experience. Once the kmod binary cache is in the 
VFS page buffer cache, it is really fast getting a new context even in new 
processes. The expensive thing about udev is that it starts very fast forking 
off worker processes. So at least one new context per process is created 
finally too. Additionally, the people who decide to use systemd-modules-load to 
load specific modules have good reasons for that. A prominent one is probably 
that udevd is not working for the respective module because no concrete device 
is coupled with it. I think we do not have so many kernel modules, which need 
to be handled like this which brings us again to the question if it is really 
worth pimping systemd-modules-load. 

 For the don't load until it's needed I very much prefer the static
 nodes approach we have. Shouldn't this be used instead of filling
 modules-load-d with lots of entries?

We are not using systemd-modules-load for applying this approach since it is 
trying to load all modules in one shot. We are executing our tool several times 
during startup to get up hardware piece by piece exactly at the point where it 
is needed. The tool is either executed like modprobe or with a configuration 
file containing a set of modules to be loaded in one shot and some other stuff 
needed for synchronization and setup.

 
 I really miss numbers here and more information on which modules are
 taking long because they are serialized.
 
 --
 Lucas De Marchi


Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] hwdb: add rule and first entry for PS/2 mice

2014-12-23 Thread David Herrmann
(CC'ing sd-devel this time.. sorry)

On Tue, Dec 23, 2014 at 1:19 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 https://bugs.freedesktop.org/show_bug.cgi?id=87037
 ---
 some feedback on the rule would be appreciated, in case there's a better
 approach to matching.

  hwdb/70-mouse.hwdb   | 4 
  rules/70-mouse.rules | 3 +++
  2 files changed, 7 insertions(+)

 diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
 index d40e864..76bcf9b 100644
 --- a/hwdb/70-mouse.hwdb
 +++ b/hwdb/70-mouse.hwdb
 @@ -188,6 +188,10 @@ mouse:usb:v046dpc52b:name:Logitech Unifying Device. 
 Wireless PID:4026:
  mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
   MOUSE_DPI=1000@1000

 +# ImExPS/2 Logitech Wheel Mouse
 +mouse:ps2:*:name:ImExPS/2 Logitech Wheel Mouse:
 + MOUSE_DPI=400@250
 +
  ##
  # Microsoft
  ##
 diff --git a/rules/70-mouse.rules b/rules/70-mouse.rules
 index 0e359e8..4e2eb8a 100644
 --- a/rules/70-mouse.rules
 +++ b/rules/70-mouse.rules
 @@ -11,5 +11,8 @@ KERNELS==input*, ENV{ID_BUS}==usb, \
  KERNELS==input*, ENV{ID_BUS}==bluetooth, \
  IMPORT{builtin}=hwdb 
 'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:', \
  GOTO=mouse_end
 +DRIVERS==psmouse, \
 +IMPORT{builtin}=hwdb 'mouse:ps2::name:$attr{device/name}:', \
 +GOTO=mouse_end

So 'psmouse' uses:
%s %s %s, protocol, vendor, name

Kinda disappointing that we cannot query each value individually.. but
it's 80's technology, so I guess no-one cares that much, anyway.

I'm fine with matching on the driver, but I'd prefer adding a
SUBSYSTEMS==serio (or even SUBSYSTEM? not sure, don't have a ps2
device here).

So please, go ahead and push it.

Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/9] capabilities: remove include of sys/capability.h where possible

2014-12-23 Thread David Herrmann
Hi

On Mon, Dec 22, 2014 at 8:57 PM, Filipe Brandenburger
filbran...@google.com wrote:
 Ping?

 Also wondering if it makes sense to go ahead and implement our own
 cap_to_text and cap_from_text to generate capability strings from
 the bitmaps (and further remove dependency on libcap.) I think it
 does, considering we now already have our own list of valid
 capabilities and the constants come from kernel headers (or
 missing.h), it makes sense to have more of our own routines...

 Cheers,
 Filipe


 On Tue, Dec 16, 2014 at 5:18 PM, Filipe Brandenburger
 filbran...@google.com wrote:
 This is a first cleanup step towards removing the dependency on libcap.

 The idea of removing the libcap dependency was brought up by Lennart in:
 http://lists.freedesktop.org/archives/systemd-devel/2014-December/026155.html

 It is mainly removing the include of sys/capability.h where the only
 capability-related information used is the CAP_* constants which are actually
 coming from linux/capability.h (kernel headers) or from missing.h (for
 compatibility with older kernel headers.)

 Filipe Brandenburger (9):
   capabilities: remove spurious include of sys/capability.h from nspawn.c
   capabilities: remove spurious include of sys/capability.h from logind 
 sources
   capabilities: remove spurious include of sys/capability.h from tmpfiles.c
   capabilities: remove spurious include of sys/capability.h from 
 hostnamed.c
   capabilities: remove spurious include of sys/capability.h from localed.c
   capabilities: remove spurious include of sys/capability.h from 
 timedated.c
   capabilities: remove spurious include of sys/capability.h from 
 pam_systemd.c
   capabilities: remove spurious include of sys/capability.h from machined 
 sources
   capabilities: remove spurious include of sys/capability.h from sd-dbus 
 sources

I cannot find these patches on systemd-devel@lists.freedesktop.org.
This might be due to fdo mail-server issues, or me just being
incapable of searching through my emails... Anyway, would you mind
resending those? While at it, they look like you can merge all this
into a single patch.

Thanks
David

  src/hostname/hostnamed.c| 1 -
  src/libsystemd/sd-bus/bus-objects.c | 2 --
  src/libsystemd/sd-bus/bus-util.c| 1 -
  src/locale/localed.c| 1 -
  src/login/logind-dbus.c | 1 -
  src/login/logind-seat-dbus.c| 1 -
  src/login/logind-session-dbus.c | 1 -
  src/login/logind-user-dbus.c| 1 -
  src/login/pam_systemd.c | 1 -
  src/machine/machine-dbus.c  | 1 -
  src/machine/machined-dbus.c | 1 -
  src/nspawn/nspawn.c | 2 +-
  src/timedate/timedated.c| 1 -
  src/tmpfiles/tmpfiles.c | 1 -
  14 files changed, 1 insertion(+), 15 deletions(-)

 --
 1.8.3.1

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH][Resend][RFC] core: Fix wrong timestamps in rtc-in-local time mode.

2014-12-23 Thread David Herrmann
Hi

On Thu, Dec 18, 2014 at 3:33 PM, Chunhui He hchun...@mail.ustc.edu.cn wrote:
 Hi all,

 When the system is configured to read the RTC time in the local time zone,
 some timestamps recorded by systemd are wrong.

Apparently, you never received Lennart's reply on your original mail.
Below, you can find his original comment.

Thanks
David


Quoting Lennart:


I am not really convinced that we really should try to make this
work. rtc-in-local-time has so many issues, it really doesn't stop
here. If people make use of this, then this is what they get really,
and I am not sure we really should work around it. I mean, systemd
really isn't the only component which might query the clock this
early, in the initrd there might be a ton of other components too, and
it's not realistic to add similar kludges to them all.

In general: rtc-in-local-time is a compatibility hack, and we only
want to support it to the minimal level necessary for compatibility,
but not more. The proper fix for this problem I guess is to use
rtc-in-utc instead!

Sorry if that's disappointing,

Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-23 Thread Tom Gundersen
On Tue, Dec 23, 2014 at 12:25 PM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 Some numbers to the above mentioned arguments:
 - in an idle system, systemd-udev-trigger.service takes by about 150-200ms 
 just to get the complete device tree to send out add uevents again (udevd 
 was deactivated while doing this measure)

I'm working on optimizing this a bit (though we are obviously talking
about percentage points, not orders of magnitude). I'd be interested
in seeing if it could be further optimized to help your usecase once I
have pushed out the basic rework.

 - the processing of the resulting uevents by udevd takes 1-2 seconds (with 
 the default rule set) again in an idle system

I haven't looked at this much recently, but if you find any
bottlenecks, do shout so we can look at improving it if possible.

 - in a general solution, we'd need to wait for udevd to completely settle 
 until we can start using the devices

Hm, I would question this. In a semi-modern system you should not need
to wait for settle at all, as everything should be hotplug capable. If
you are in total control of your software (which I assume you are),
you should be able to fix the non-hotplug capable software and drop
the settling. Have you tried this? What is the blocker here?

If you drop settling, then I guess the biggest tweak you can do is
with the order in which devices are triggered. I'm not seeing how we
can do something sensible about this in a generic fashion, but might
be worth fiddling with to figure out what is the optimal order on your
system (to have a baseline for future optimizations).

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] util: fix strict aliasing violations in use of struct inotify_event v3

2014-12-23 Thread Lennart Poettering
On Mon, 22.12.14 18:54, Shawn Paul Landden (sh...@churchofgit.com) wrote:

 There is alot of cleanup that will have to happen to turn on
 -fstrict-aliasing, but I think our code should be correct to the
 rule.

Hmm, this seems incomplete, mount.c and path.c also use the structure?

Also, maybe the FOREACH_INOTIFY_EVENT() should be updated slightly, to
take one of the unions as parameter now...

 
 v2: move union def to header file
 v3: fix syntax
 ---
  src/journal/sd-journal.c | 6 +++---
  src/shared/util.c| 7 +++
  src/shared/util.h| 6 ++
  src/udev/udevd.c | 6 +++---
  4 files changed, 15 insertions(+), 10 deletions(-)
 
 diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
 index d46dc3c..83be4c9 100644
 --- a/src/journal/sd-journal.c
 +++ b/src/journal/sd-journal.c
 @@ -2188,11 +2188,11 @@ _public_ int sd_journal_process(sd_journal *j) {
  j-last_process_usec = now(CLOCK_MONOTONIC);
  
  for (;;) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
 inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 -l = read(j-inotify_fd, buffer, sizeof(buffer));
 +l = read(j-inotify_fd, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EAGAIN || errno == EINTR)
  return got_something ? determine_change(j) : 
 SD_JOURNAL_NOP;
 @@ -2202,7 +2202,7 @@ _public_ int sd_journal_process(sd_journal *j) {
  
  got_something = true;
  
 -FOREACH_INOTIFY_EVENT(e, buffer, l)
 +FOREACH_INOTIFY_EVENT(e, buffer.ev, l)
  process_inotify_event(j, e);
  }
  }
 diff --git a/src/shared/util.c b/src/shared/util.c
 index 06b6077..fc83da9 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -39,7 +39,6 @@
  #include linux/tiocl.h
  #include termios.h
  #include stdarg.h
 -#include sys/inotify.h
  #include sys/poll.h
  #include ctype.h
  #include sys/prctl.h
 @@ -2106,7 +2105,7 @@ int acquire_terminal(
  assert(notify = 0);
  
  for (;;) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
 inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 @@ -2129,7 +2128,7 @@ int acquire_terminal(
  }
  }
  
 -l = read(notify, buffer, sizeof(buffer));
 +l = read(notify, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EINTR || errno == EAGAIN)
  continue;
 @@ -2138,7 +2137,7 @@ int acquire_terminal(
  goto fail;
  }
  
 -FOREACH_INOTIFY_EVENT(e, buffer, l) {
 +FOREACH_INOTIFY_EVENT(e, buffer.ev, l) {
  if (e-wd != wd || !(e-mask  IN_CLOSE)) {
  r = -EIO;
  goto fail;
 diff --git a/src/shared/util.h b/src/shared/util.h
 index 1804b8c..b97d8af 100644
 --- a/src/shared/util.h
 +++ b/src/shared/util.h
 @@ -42,6 +42,7 @@
  #include locale.h
  #include mntent.h
  #include sys/socket.h
 +#include sys/inotify.h
  
  #if SIZEOF_PID_T == 4
  #  define PID_FMT % PRIu32
 @@ -1051,4 +1052,9 @@ int sethostname_idempotent(const char *s);
   (uint8_t*) (e)  (uint8_t*) (buffer) + (sz); \
   (e) = (struct inotify_event*) ((uint8_t*) (e) + sizeof(struct 
 inotify_event) + (e)-len))
  
 +typedef union {
 +struct inotify_event ev;
 +uint8_t raw[INOTIFY_EVENT_MAX];
 +} inotify_event_buffer_t;
 +
  #define laccess(path, mode) faccessat(AT_FDCWD, (path), (mode), 
 AT_SYMLINK_NOFOLLOW)
 diff --git a/src/udev/udevd.c b/src/udev/udevd.c
 index 8bec03e..bd13025 100644
 --- a/src/udev/udevd.c
 +++ b/src/udev/udevd.c
 @@ -816,11 +816,11 @@ static int synthesize_change(struct udev_device *dev) {
  }
  
  static int handle_inotify(struct udev *udev) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 -l = read(fd_inotify, buffer, sizeof(buffer));
 +l = read(fd_inotify, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EAGAIN || errno == EINTR)
  return 0;
 @@ -828,7 +828,7 @@ static int handle_inotify(struct udev *udev) {
  return log_error_errno(errno, Failed to read inotify fd: 
 %m);
  }
  
 -FOREACH_INOTIFY_EVENT(e, buffer, l) {
 +

Re: [systemd-devel] Improving module loading

2014-12-23 Thread Tom Gundersen
On Tue, Dec 23, 2014 at 1:21 PM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 -Original Message-
 From: Lucas De Marchi [mailto:lucas.de.mar...@gmail.com]
 Sent: Monday, December 22, 2014 7:00 PM
 To: Lennart Poettering
 Cc: Hoyer, Marko (ADITG/SW2); systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] Improving module loading

 On Mon, Dec 22, 2014 at 1:04 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Sat, 20.12.14 10:45, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-
 jv.com) wrote:
 
  I had such a discussion earlier with some of the systemd guys. My
  intention was to introduce an additional unit for module loading for
  exactly the reason you mentioned. The following (reasonable) outcome
  was:
 
  - It is dangerous to load kernel modules from PID 1 since module
loading can get stuck
 
  - Since modules are actually loaded with the thread that calls the
syscall, systemd would need additional threads
 
  - Multi Threading is not really aimed in systemd for stability
  reasons
 
  The probably safest way to do what you intended is to use an
  additional process to load your modules, which could be easily done
  by using ExecStartPre= in a service file. We are doing it exactly
  this way not with kmod but with a tool that loads modules in
  parallel.
 
  I'd be willing to merge a good patch that beefs up
  systemd-modules-load to load the specified modules in parallel, with
  one thread for each.
 
  We already have a very limited number of threaded bits in systemd,
 and
  I figure out would be OK to do that for this too.
 
  Please keep the threading minimal though, i.e. one kmod context per
  thread, so that we need no synchronization and no locking. One thread
  per module, i.e. no worker thread logic with thread reusing. also,
  please set a thred name, so that hanging module loading only hang one
  specific thread and the backtrace shows which module is at fault.

 I'm skeptical you would get any speed up for that. I think it would be
 better to have some numbers shared before merging such a thing.


 As I already outlined in my answer to Greg, the parallel loading was not our 
 main motivation for inventing something new. We found that for some of our 
 modules parallel loading gained us benefit, so we integrated this feature. 
 Since we are not using udevd during startup at all, most of our modules are 
 loaded manually. I've no idea how things are distributed between 
 systemd-modules-load and udevd in conventional Linux desktop or server 
 systems. If only a hand full of modules are actually loaded using 
 systemd-modules-load, it is probably not worth optimizing at this end.

 Has someone concrete numbers how many modules are loaded by hand using 
 systemd-modules-load in a conventional system?

In a stock Fedora/Arch (and probably others, but didn't check)
systemd-modules-load is not used at all. It is mostly there to make it
simple to work around sub-par kernel modules, but most have been fixed
by now, so it is increasingly irrelevant.

I agree that it is probably not worth doing lots of
systemd-modules-load-specific hacks to speed it up, but if we split
out the worker-pool logic from udev (which I'm currently working at as
we need it in more places), we can optimize that in a generic way and
if the numbers show that systemd-modules-load would benefit from using
it, I'd be all for hooking that up too (as doing so would then be
trivial).

 If you have 1 context per module/thread you will need to initialize
 each context which is really the most expensive part in userspace,
 particularly if finit_module() is being used (which you should unless
 you have restrictions on the physical size taken by the modules). Bare
 in mind the udev logic has only 1 context, so the initialization is
 amortized among the multiple module load calls.


 This does not really meet my experience. Once the kmod binary cache is in the 
 VFS page buffer cache, it is really fast getting a new context even in new 
 processes. The expensive thing about udev is that it starts very fast forking 
 off worker processes. So at least one new context per process is created 
 finally too. Additionally, the people who decide to use systemd-modules-load 
 to load specific modules have good reasons for that. A prominent one is 
 probably that udevd is not working for the respective module because no 
 concrete device is coupled with it. I think we do not have so many kernel 
 modules, which need to be handled like this which brings us again to the 
 question if it is really worth pimping systemd-modules-load.

I'm not aware of any kernel modules that legitimately needs to be
loaded in this way (i.e., all the ones that do can/should be fixed).

 For the don't load until it's needed I very much prefer the static
 nodes approach we have. Shouldn't this be used instead of filling
 modules-load-d with lots of entries?

 We are not using systemd-modules-load for applying this approach since it 

Re: [systemd-devel] [PATCH 2/2] test: wait for cloned thread to exit

2014-12-23 Thread Lennart Poettering
On Mon, 22.12.14 11:57, Filipe Brandenburger (filbran...@google.com) wrote:

 Ping?

I got none of these emails, and they are neither shown in the mailing
list archives. There must be something wrong in the mail delivery
between google.com and fdo?

 On Thu, Dec 18, 2014 at 11:24 AM, Filipe Brandenburger
 filbran...@google.com wrote:
  In test_raw_clone, make sure the cloned thread calls _exit() and in the 
  parent
  thread call waitpid(..., __WCLONE) to wait for the child thread to 
  terminate,
  otherwise there is a race condition where the child thread will log to the
  console after the test process has already exited and the assertion from the
  child thread might not be enforced.
 
  The absence of this patch might also create problems for other tests that 
  would
  be added after this one, since potentially both parent and child would run
  those tests as the child would continue running.
 
  Tested by confirming that the logs from the child are printed before the 
  test
  terminates and that a false assertion in the child aborts the test with a 
  core
  dump.
  ---
   src/test/test-util.c | 9 +++--
   1 file changed, 7 insertions(+), 2 deletions(-)
 
  diff --git a/src/test/test-util.c b/src/test/test-util.c
  index ec04744..997e3df 100644
  --- a/src/test/test-util.c
  +++ b/src/test/test-util.c
  @@ -1325,10 +1325,15 @@ static void test_raw_clone(void) {
   pid2 = raw_getpid();
   log_info(raw_clone: PID_FMT getpid()→PID_FMT 
  raw_getpid()→PID_FMT,
pid, getpid(), pid2);
  -if (pid == 0)
  +if (pid == 0) {
   assert_se(pid2 != parent);
  -else
  +_exit(EXIT_SUCCESS);
  +} else {
  +int status;
   assert_se(pid2 == parent);
  +
  +waitpid(pid, status, __WCLONE);
  +}
   }
 
   int main(int argc, char *argv[]) {
  --
  1.8.3.1
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] util: fix strict aliasing violations in use of struct inotify_event v3

2014-12-23 Thread Lennart Poettering
On Mon, 22.12.14 18:54, Shawn Paul Landden (sh...@churchofgit.com) wrote:

 There is alot of cleanup that will have to happen to turn on
 -fstrict-aliasing, but I think our code should be correct to the rule.

BTW, not sure how you are getting these emails, but apparently you do
given that you reply, maybe via the ML... All mails sent to you are
bouncing:

sh...@churchofgit.com: host mail.churchofgit.com[198.20.106.155] said: 554
5.7.1 sh...@churchofgit.com: Relay access denied (in reply to
RCPT TO command)


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-23 Thread Tom Gundersen
On Tue, Dec 23, 2014 at 12:25 PM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 Some numbers to the above mentioned arguments:
 - in an idle system, systemd-udev-trigger.service takes by about 150-200ms 
 just to get the complete device tree to send out add uevents again (udevd 
 was deactivated while doing this measure)

I'm working on optimizing this a bit (though we are obviously talking
about percentage points, not orders of magnitude). I'd be interested
in seeing if it could be further optimized to help your usecase once I
have pushed out the basic rework.

 - the processing of the resulting uevents by udevd takes 1-2 seconds (with 
 the default rule set) again in an idle system

I haven't looked at this much recently, but if you find any
bottlenecks, do shout so we can look at improving it if possible.

 - in a general solution, we'd need to wait for udevd to completely settle 
 until we can start using the devices

Hm, I would question this. In a semi-modern system you should not need
to wait for settle at all, as everything should be hotplug capable. If
you are in total control of your software (which I assume you are),
you should be able to fix the non-hotplug capable software and drop
the settling. Have you tried this? What is the blocker here?

If you drop settling, then I guess the biggest tweak you can do is
with the order in which devices are triggered. I'm not seeing how we
can do something sensible about this in a generic fashion, but might
be worth fiddling with to figure out what is the optimal order on your
system (to have a baseline for future optimizations).

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-23 Thread Kay Sievers
On Tue, Dec 23, 2014 at 3:22 PM, Tom Gundersen t...@jklm.no wrote:
 On Tue, Dec 23, 2014 at 12:25 PM, Hoyer, Marko (ADITG/SW2)
 mho...@de.adit-jv.com wrote:
 Some numbers to the above mentioned arguments:
 - in an idle system, systemd-udev-trigger.service takes by about 150-200ms 
 just to get the complete device tree to send out add uevents again (udevd 
 was deactivated while doing this measure)

 I'm working on optimizing this a bit (though we are obviously talking
 about percentage points, not orders of magnitude). I'd be interested
 in seeing if it could be further optimized to help your usecase once I
 have pushed out the basic rework.

This is in most cases caused by conceptually broken implementations of
drivers or subsystems which call into the driver or event the firmware
when the uevent file is read by userspace.

Subsystems like power_supply had the great idea to transport device
measurement data over uevents. This can't be fixed from userspace, it
would need to be fixed in the kernel.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-gpt-auto-generator does not appear to remount rootfs rw

2014-12-23 Thread Dimitri John Ledkov
I'm using systemd 218 (stock upstream, unpatched)  dracut 040 (stock
upstream, unpatched).

I'm trying to build a basic GPT disk image to boot in a VM with
gpt-auto-generator discovery of partitions.

I create three partitions: ESP, swap and rootfs with the following type ids set:
sgdisk /dev/loop6 --typecode=1:c12a7328-f81f-11d2-ba4b-00a0c93ec93b
sgdisk /dev/loop6 --typecode=2:0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
sgdisk /dev/loop6 --typecode=3:4f68bce3-e8cd-4db1-96e7-fbcaf984b709

In addition to that I clear the no-auto-mount and read-only attributes:
sgdisk /dev/loop6 --attributes=1:clear:60
sgdisk /dev/loop6 --attributes=1:clear:63
sgdisk /dev/loop6 --attributes=3:clear:60
sgdisk /dev/loop6 --attributes=3:clear:63

Thus I am expecting for the gpt-auto-generator to work correctly.

It does boot with and without initramfs, however in such configuration
the root filesystem (3rd partition in this case) is mounted read-only
and a few of standard systemd units fail. As per documentation, I had
the impression that rootfs should be mounted read-write in such
configuration.

To mitigated this problem I came up with two workarounds:
* add rw to the kernel cmdline
* add /etc/fstab with a single entry like this one:
/dev/gpt-auto-root / none   defaults,rw

Is this correct additional requirements to get rw rootfs? Or is
there a bug, and either of the workarounds are not required? Or are my
type ids/attributes set wrongly on the partitions?

-- 
Ho Ho Ho,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-gpt-auto-generator does not appear to remount rootfs rw

2014-12-23 Thread Dimitri John Ledkov
On 23/12/14 16:56, Dimitri John Ledkov wrote:
 I'm using systemd 218 (stock upstream, unpatched)  dracut 040 (stock
 upstream, unpatched).
 
 I'm trying to build a basic GPT disk image to boot in a VM with
 gpt-auto-generator discovery of partitions.
 
 I create three partitions: ESP, swap and rootfs with the following type ids 
 set:
 sgdisk /dev/loop6 --typecode=1:c12a7328-f81f-11d2-ba4b-00a0c93ec93b
 sgdisk /dev/loop6 --typecode=2:0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
 sgdisk /dev/loop6 --typecode=3:4f68bce3-e8cd-4db1-96e7-fbcaf984b709
 
 In addition to that I clear the no-auto-mount and read-only attributes:
 sgdisk /dev/loop6 --attributes=1:clear:60
 sgdisk /dev/loop6 --attributes=1:clear:63
 sgdisk /dev/loop6 --attributes=3:clear:60
 sgdisk /dev/loop6 --attributes=3:clear:63
 
 Thus I am expecting for the gpt-auto-generator to work correctly.
 
 It does boot with and without initramfs, however in such configuration
 the root filesystem (3rd partition in this case) is mounted read-only
 and a few of standard systemd units fail. As per documentation, I had
 the impression that rootfs should be mounted read-write in such
 configuration.
 
 To mitigated this problem I came up with two workarounds:
 * add rw to the kernel cmdline
 * add /etc/fstab with a single entry like this one:
 /dev/gpt-auto-root / none   defaults,rw
 
 Is this correct additional requirements to get rw rootfs? Or is
 there a bug, and either of the workarounds are not required? Or are my
 type ids/attributes set wrongly on the partitions?
 

Hm, looking at source code arg_root_rw is never set to true if for root 
partition flags ^ GPT_FLAG_READ_ONLY is true.
I'll write a patch, unless it's intentional to only parse kernel cmdline to set 
arg_root_rw.

-- 
Regards,

Dimitri.



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/2] test: only use assert_se in test_raw_clone

2014-12-23 Thread Filipe Brandenburger
The asserts used in the tests should never be allowed to be optimized away.
---
 src/test/test-util.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/test/test-util.c b/src/test/test-util.c
index 222af9a..57fd19b 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -420,7 +420,7 @@ static void check(const char *test, char** expected, bool 
trailing) {
 printf(%s\n, t);
 }
 printf(%s\n, state);
-assert(expected[i] == NULL);
+assert_se(expected[i] == NULL);
 assert_se(isempty(state) == !trailing);
 }
 
@@ -1331,15 +1331,15 @@ static void test_raw_clone(void) {
 assert_se(raw_getpid() == parent);
 
 pid = raw_clone(0, NULL);
-assert(pid = 0);
+assert_se(pid = 0);
 
 pid2 = raw_getpid();
 log_info(raw_clone: PID_FMT getpid()→PID_FMT 
raw_getpid()→PID_FMT,
  pid, getpid(), pid2);
 if (pid == 0)
-assert(pid2 != parent);
+assert_se(pid2 != parent);
 else
-assert(pid2 == parent);
+assert_se(pid2 == parent);
 }
 
 int main(int argc, char *argv[]) {
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/2] test: wait for cloned thread to exit

2014-12-23 Thread Filipe Brandenburger
In test_raw_clone, make sure the cloned thread calls _exit() and in the parent
thread call waitpid(..., __WCLONE) to wait for the child thread to terminate,
otherwise there is a race condition where the child thread will log to the
console after the test process has already exited and the assertion from the
child thread might not be enforced.

The absence of this patch might also create problems for other tests that would
be added after this one, since potentially both parent and child would run
those tests as the child would continue running.

Tested by confirming that the logs from the child are printed before the test
terminates and that a false assertion in the child aborts the test with a core
dump.
---
 src/test/test-util.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/test/test-util.c b/src/test/test-util.c
index 57fd19b..f88ef2e 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -1336,10 +1336,15 @@ static void test_raw_clone(void) {
 pid2 = raw_getpid();
 log_info(raw_clone: PID_FMT getpid()→PID_FMT 
raw_getpid()→PID_FMT,
  pid, getpid(), pid2);
-if (pid == 0)
+if (pid == 0) {
 assert_se(pid2 != parent);
-else
+_exit(EXIT_SUCCESS);
+} else {
+int status;
 assert_se(pid2 == parent);
+
+waitpid(pid, status, __WCLONE);
+}
 }
 
 int main(int argc, char *argv[]) {
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 2/2] test: wait for cloned thread to exit

2014-12-23 Thread Filipe Brandenburger
Hi,

On Tue, Dec 23, 2014 at 6:43 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 22.12.14 11:57, Filipe Brandenburger (filbran...@google.com) wrote:
 Ping?

 I got none of these emails, and they are neither shown in the mailing
 list archives. There must be something wrong in the mail delivery
 between google.com and fdo?

Indeed, that seemed to be the case...

I set up a different smtp server and resent, from the mailing list
archives looks like it was delivered this time:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026521.html

I'll rebase and resend all others.

Thanks!
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 0/9] capabilities: remove include of sys/capability.h where possible

2014-12-23 Thread Filipe Brandenburger
This is a first cleanup step towards removing the dependency on libcap.

The idea of removing the libcap dependency was brought up by Lennart in:
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026155.html

It is mainly removing the include of sys/capability.h where the only
capability-related information used is the CAP_* constants which are actually
coming from linux/capability.h (kernel headers) or from missing.h (for
compatibility with older kernel headers.)

Filipe Brandenburger (9):
  capabilities: remove spurious include of sys/capability.h from nspawn.c
  capabilities: remove spurious include of sys/capability.h from logind 
sources
  capabilities: remove spurious include of sys/capability.h from tmpfiles.c
  capabilities: remove spurious include of sys/capability.h from hostnamed.c
  capabilities: remove spurious include of sys/capability.h from localed.c
  capabilities: remove spurious include of sys/capability.h from timedated.c
  capabilities: remove spurious include of sys/capability.h from pam_systemd.c
  capabilities: remove spurious include of sys/capability.h from machined 
sources
  capabilities: remove spurious include of sys/capability.h from sd-dbus 
sources

 src/hostname/hostnamed.c| 1 -
 src/libsystemd/sd-bus/bus-objects.c | 2 --
 src/libsystemd/sd-bus/bus-util.c| 1 -
 src/locale/localed.c| 1 -
 src/login/logind-dbus.c | 1 -
 src/login/logind-seat-dbus.c| 1 -
 src/login/logind-session-dbus.c | 1 -
 src/login/logind-user-dbus.c| 1 -
 src/login/pam_systemd.c | 1 -
 src/machine/machine-dbus.c  | 1 -
 src/machine/machined-dbus.c | 1 -
 src/nspawn/nspawn.c | 2 +-
 src/timedate/timedated.c| 1 -
 src/tmpfiles/tmpfiles.c | 1 -
 14 files changed, 1 insertion(+), 15 deletions(-)

-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 4/9] capabilities: remove spurious include of sys/capability.h from hostnamed.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions from libcap directly. The CAP_SYS_ADMIN constant
in use by this file comes from linux/capability.h imported through 
missing.h.

Tested that systemd-hostnamed builds cleanly and works after this change.
---
 src/hostname/hostnamed.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index ef45e56..b230ff6 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -23,7 +23,6 @@
 #include string.h
 #include unistd.h
 #include sys/utsname.h
-#include sys/capability.h
 
 #include util.h
 #include strv.h
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 3/9] capabilities: remove spurious include of sys/capability.h from tmpfiles.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions from libcap directly. The CAP_MKNOD constant in
use by this file comes from linux/capability.h imported through missing.h.

Tested that systemd-tmpfiles builds cleanly and works after this change.
---
 src/tmpfiles/tmpfiles.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index d40bd96..44ea51e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -38,7 +38,6 @@
 #include sys/param.h
 #include glob.h
 #include fnmatch.h
-#include sys/capability.h
 #include sys/xattr.h
 
 #include log.h
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 7/9] capabilities: remove spurious include of sys/capability.h from pam_systemd.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions or constants from libcap directly.

Tested that pam_systemd.la builds cleanly and works after this change.
---
 src/login/pam_systemd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/login/pam_systemd.c b/src/login/pam_systemd.c
index 111e2b7..d5b29c8 100644
--- a/src/login/pam_systemd.c
+++ b/src/login/pam_systemd.c
@@ -24,7 +24,6 @@
 #include sys/file.h
 #include pwd.h
 #include endian.h
-#include sys/capability.h
 
 #include security/pam_modules.h
 #include security/_pam_macros.h
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 6/9] capabilities: remove spurious include of sys/capability.h from timedated.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions from libcap directly. The CAP_SYS_TIME constant
in use by this file comes from linux/capability.h imported through 
missing.h.

Tested that systemd-timedated builds cleanly and works after this change.
---
 src/timedate/timedated.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index bf567a1..d507200 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -22,7 +22,6 @@
 #include errno.h
 #include string.h
 #include unistd.h
-#include sys/capability.h
 
 #include sd-id128.h
 #include sd-messages.h
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/9] capabilities: remove spurious include of sys/capability.h from nspawn.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions from libcap directly. The CAP_* constants in use
through this file come from missing.h which will import linux/capability.h
and complement it with CAP_* constants not defined by the current kernel
headers.

Add an explicit import of our capability.h since it does use the function
capability_bounding_set_drop from that header file. Previously, that header was
implicitly imported through through cap-list.h.

Tested that systemd-nspawn builds cleanly and works after this change.
---
 src/nspawn/nspawn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0dd12ad..04396eb 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -31,7 +31,6 @@
 #include stdio.h
 #include errno.h
 #include sys/prctl.h
-#include sys/capability.h
 #include getopt.h
 #include termios.h
 #include sys/signalfd.h
@@ -90,6 +89,7 @@
 #include base-filesystem.h
 #include barrier.h
 #include event-util.h
+#include capability.h
 #include cap-list.h
 #include btrfs-util.h
 
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 8/9] capabilities: remove spurious include of sys/capability.h from machined sources

2014-12-23 Thread Filipe Brandenburger
They do not use any functions from libcap directly. The CAP_KILL constant in
use by these files comes from linux/capability.h imported through
missing.h.

Tested that systemd-machined builds cleanly and works after this change.
---
 src/machine/machine-dbus.c  | 1 -
 src/machine/machined-dbus.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c
index 76c5dcf..7855c4c 100644
--- a/src/machine/machine-dbus.c
+++ b/src/machine/machine-dbus.c
@@ -21,7 +21,6 @@
 
 #include errno.h
 #include string.h
-#include sys/capability.h
 #include arpa/inet.h
 
 #include bus-util.h
diff --git a/src/machine/machined-dbus.c b/src/machine/machined-dbus.c
index 370d04a..ffb7722 100644
--- a/src/machine/machined-dbus.c
+++ b/src/machine/machined-dbus.c
@@ -23,7 +23,6 @@
 #include string.h
 #include unistd.h
 #include pwd.h
-#include sys/capability.h
 
 #include sd-id128.h
 #include sd-messages.h
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 5/9] capabilities: remove spurious include of sys/capability.h from localed.c

2014-12-23 Thread Filipe Brandenburger
It does not use any functions from libcap directly. The CAP_SYS_ADMIN constant
in use by this file comes from linux/capability.h imported through 
missing.h.

Tested that systemd-localed builds cleanly and works after this change.
---
 src/locale/localed.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/locale/localed.c b/src/locale/localed.c
index 0aaa63d..0723541 100644
--- a/src/locale/localed.c
+++ b/src/locale/localed.c
@@ -23,7 +23,6 @@
 #include errno.h
 #include string.h
 #include unistd.h
-#include sys/capability.h
 
 #include sd-bus.h
 
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 9/9] capabilities: remove spurious include of sys/capability.h from sd-dbus sources

2014-12-23 Thread Filipe Brandenburger
They do not use any functions from libcap directly. The CAP_SYS_ADMIN constant
in use by bus-objects.c comes from linux/capability.h imported through
missing.h. The missing.h header is imported through util.h which gets
imported in bus-util.h.

Tested that everything builds cleanly after this change.
---
 src/libsystemd/sd-bus/bus-objects.c | 2 --
 src/libsystemd/sd-bus/bus-util.c| 1 -
 2 files changed, 3 deletions(-)

diff --git a/src/libsystemd/sd-bus/bus-objects.c 
b/src/libsystemd/sd-bus/bus-objects.c
index 6162d12..e64743f 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -19,8 +19,6 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
-#include sys/capability.h
-
 #include strv.h
 #include set.h
 #include bus-internal.h
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index 0f1a89c..06e6d84 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -20,7 +20,6 @@
 ***/
 
 #include sys/socket.h
-#include sys/capability.h
 
 #include systemd/sd-daemon.h
 
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/9] capabilities: remove include of sys/capability.h where possible

2014-12-23 Thread Filipe Brandenburger
On Tue, Dec 23, 2014 at 5:23 AM, David Herrmann dh.herrm...@gmail.com wrote:
 I cannot find these patches on systemd-devel@lists.freedesktop.org.
 This might be due to fdo mail-server issues, or me just being
 incapable of searching through my emails... Anyway, would you mind
 resending those?

Yeah, it seems I was having trouble... Looks like I fixed it, at least
I can see the messages I just resent on the mailing list archive.

 While at it, they look like you can merge all this into a single patch.

I see. The main reason for it was that I used the commit description
to document that it is safe to remove from every place. If you'd
really like I can squash them all myself or feel free to squash them
while applying, that's certainly fine with me.

Thanks!
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv2] update .gitignore to include test-lldp

2014-12-23 Thread Filipe Brandenburger
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 1b5d60f..078fd9a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -207,6 +207,7 @@
 /test-libudev-sym*
 /test-list
 /test-unaligned
+/test-lldp
 /test-locale-util
 /test-local-addresses
 /test-log
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv2 1/2] build-sys: do not use pkgconfig dbus-1.pc to find dbus directories

2014-12-23 Thread Filipe Brandenburger
Do not use the dbus-1.pc pkgconfig settings to determine dbus directories. Use
directories relative to ${sysconfdir} and ${datadir} instead.

This approach was suggested by Simon McVittie in:
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024388.html

Tested by building and installing systemd without the dbus-devel installed.
Without this patch, the dbus files and directories end up in the root of the
filesystem. With this patch, they end up in the same locations as previously
(assuming default ${sysconfdir} and ${datadir}) whether dbus-devel is present
or not. Also made sure that `make check` works without dbus-devel installed.
---
v2: Updated TODO to remove entry about pkg-config dbus-1.

 TODO | 2 --
 configure.ac | 8 
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/TODO b/TODO
index fdc37b1..6ff9b8f 100644
--- a/TODO
+++ b/TODO
@@ -126,8 +126,6 @@ Features:
 
 * systemd --user should issue sd_notify() upon reaching basic.target, not on 
becoming idle
 
-* configure.ac pretends dbus was optional but actually hardcodes use of dbus' 
pkg-config file to determine various dbus dirs such as policy and activation 
dirs
-
 * consider showing the unit names during boot up in the status output, not 
just the unit descriptions
 
 * dhcp: do we allow configuring dhcp routes on interfaces that are not the one 
we got the dhcp info from?
diff --git a/configure.ac b/configure.ac
index 0e72166..f20c0e7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1258,22 +1258,22 @@ AC_SUBST(TTY_GID)
 AC_ARG_WITH([dbuspolicydir],
 AS_HELP_STRING([--with-dbuspolicydir=DIR], [D-Bus policy directory]),
 [],
-[with_dbuspolicydir=$($PKG_CONFIG --variable=sysconfdir 
dbus-1)/dbus-1/system.d])
+[with_dbuspolicydir=${sysconfdir}/dbus-1/system.d])
 
 AC_ARG_WITH([dbussessionservicedir],
 AS_HELP_STRING([--with-dbussessionservicedir=DIR], [D-Bus session 
service directory]),
 [],
-[with_dbussessionservicedir=$($PKG_CONFIG 
--variable=session_bus_services_dir dbus-1)])
+[with_dbussessionservicedir=${datadir}/dbus-1/services])
 
 AC_ARG_WITH([dbussystemservicedir],
 AS_HELP_STRING([--with-dbussystemservicedir=DIR], [D-Bus system 
service directory]),
 [],
-[with_dbussystemservicedir=$(readlink -m $($PKG_CONFIG 
--variable=session_bus_services_dir dbus-1)/../system-services)])
+[with_dbussystemservicedir=${datadir}/dbus-1/system-services])
 
 AC_ARG_WITH([dbusinterfacedir],
 AS_HELP_STRING([--with-dbusinterfacedir=DIR], [D-Bus interface 
directory]),
 [],
-[with_dbusinterfacedir=$(readlink -m $($PKG_CONFIG 
--variable=session_bus_services_dir dbus-1)/../interfaces)])
+[with_dbusinterfacedir=${datadir}/dbus-1/interfaces])
 
 AC_ARG_WITH([bashcompletiondir],
 AS_HELP_STRING([--with-bashcompletiondir=DIR], [Bash completions 
directory]),
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv2 2/2] build-sys: remove references to dbusinterfacedir

2014-12-23 Thread Filipe Brandenburger
This directory is not used by systemd.

Tested by running a full build, running `make install` and comparing the file
list in the target trees and making sure that `make distcheck` still works.
---
 configure.ac | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index f20c0e7..2348dac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1270,11 +1270,6 @@ AC_ARG_WITH([dbussystemservicedir],
 [],
 [with_dbussystemservicedir=${datadir}/dbus-1/system-services])
 
-AC_ARG_WITH([dbusinterfacedir],
-AS_HELP_STRING([--with-dbusinterfacedir=DIR], [D-Bus interface 
directory]),
-[],
-[with_dbusinterfacedir=${datadir}/dbus-1/interfaces])
-
 AC_ARG_WITH([bashcompletiondir],
 AS_HELP_STRING([--with-bashcompletiondir=DIR], [Bash completions 
directory]),
 [],
@@ -1373,7 +1368,6 @@ test -z $enable_debug  enable_debug=none
 AC_SUBST([dbuspolicydir], [$with_dbuspolicydir])
 AC_SUBST([dbussessionservicedir], [$with_dbussessionservicedir])
 AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir])
-AC_SUBST([dbusinterfacedir], [$with_dbusinterfacedir])
 AC_SUBST([bashcompletiondir], [$with_bashcompletiondir])
 AC_SUBST([zshcompletiondir], [$with_zshcompletiondir])
 AC_SUBST([pamlibdir], [$with_pamlibdir])
@@ -1476,7 +1470,6 @@ AC_MSG_RESULT([
 D-Bus policy dir:${with_dbuspolicydir}
 D-Bus session dir:   ${with_dbussessionservicedir}
 D-Bus system dir:${with_dbussystemservicedir}
-D-Bus interfaces dir:${with_dbusinterfacedir}
 Bash completions dir:${with_bashcompletiondir}
 Zsh completions dir: ${with_zshcompletiondir}
 Extra start script:  ${RC_LOCAL_SCRIPT_PATH_START}
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [systemd-commits] 8 commits - Makefile.am TODO src/bus-proxyd src/core src/import src/libsystemd src/machine src/shared src/test

2014-12-23 Thread Filipe Brandenburger
Hi,

On Tue, Dec 23, 2014 at 10:15 AM, Lennart Poettering
lenn...@kemper.freedesktop.org wrote:
 commit 3c70e3bb022f0de3317f3600c9366a2f4597339e
 Author: Lennart Poettering lenn...@poettering.net
 Date:   Tue Dec 23 18:36:04 2014 +0100

 core: rearrange code so that libsystemd/sd-bus/ does not include header 
 files from core

 Stuff in src/shared or src/libsystemd should *never* include code from
 src/core or any of the tools, so don't do that here either. It's not OK!

This commit broke the build, looks like src/core/bus-policy.[ch]
should have been added to this commit but they were not...

Cheers,
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] timesync: remove square(), use pow instead

2014-12-23 Thread Cristian Rodríguez
In any case, the compiler generates the same code inline and never
actually calls the library function.
---
 src/timesync/timesyncd-manager.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index ef5854d..117ea8c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -147,10 +147,6 @@ static double ts_to_d(const struct timespec *ts) {
 return ts-tv_sec + (1.0e-9 * ts-tv_nsec);
 }
 
-static double square(double d) {
-return d * d;
-}
-
 static int manager_timeout(sd_event_source *source, usec_t usec, void 
*userdata) {
 _cleanup_free_ char *pretty = NULL;
 Manager *m = userdata;
@@ -428,7 +424,7 @@ static bool manager_sample_spike_detection(Manager *m, 
double offset, double del
 
 j = 0;
 for (i = 0; i  ELEMENTSOF(m-samples); i++)
-j += square(m-samples[i].offset - m-samples[idx_min].offset);
+j += pow(m-samples[i].offset - m-samples[idx_min].offset, 2);
 m-samples_jitter = sqrt(j / (ELEMENTSOF(m-samples) - 1));
 
 /* ignore samples when resyncing */
-- 
2.2.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-23 Thread Greg KH
On Tue, Dec 23, 2014 at 11:25:23AM +, Hoyer, Marko (ADITG/SW2) wrote:
  What do you mean by this?  What is limiting this?  What is your limit?
  How large are these kernel modules that you are having a hard time to
  build into your kernel image?
 - As far as I remember, we have special fastboot aware partitions on the emmc 
 that are available very fast. But those are very limited in size. But with 
 this point I'm pretty much not sure. This is something I got told.
 
 - targeted kernel size: 2-3MB packed
 
 - Kernel modules:
   - we have heavy graphics drivers (~800kb, stripped), they are needed 
 half the way at startup
   - video processing unit drivers (don't know the size), they are needed 
 half the way at startup
   - wireless  bluetooth, they are needed very late
   - usb subsystem, conventionally needed very late (but this finally 
 depends on the concrete product)
   - hot plug mass storage handling, conventionally needed very late (but 
 this finally depends on the concrete product)
   - audio driver, in most of our products needed very late
   - some drivers for INC communication (partly needed very early - we 
 compiled in them, partly needed later - we have them as module)
 
 All in all I'd guess we are getting twice the size if we would compile in all 
 the stuff.

All of those should dynamically be loaded when the hardware is found by
the system, so I don't see why you are trying to load them by hand.

   - Loading the image is a kind of monolithic block in terms of time
   where you can hardly do things in parallel
  
  How long does loading a tiny kernel image actually take?
 
 I don't know exact numbers, sorry. I guess something between 50-200ms
 plus time for unpacking. But this loading and unpacking job is
 important since it is located directly on the critical path.
 

Exact numbers matter :)

   - We are strongly following the idea from Umut (loading things not
   before they are actually needed) to get up early services very early
   (e.g. rendering a camera on a display in less than 2secs after power
   on)
  
  Ah, IVI, you all have some really strange hardware configurations :(
 
 Yes IVI. Since we are developing our hardware as well as our software
 (different department), I'm interested in getting more infos about
 what is strange about IVI hardware configuration in general. Maybe we
 can improve things to a certain extent. Could you go more into
 details?

Traditionally IVI systems are _very_ underpowered, use old processors,
have tiny storage systems on very slow interfaces, very little memory,
huge numbers of IPC calls at startup due to legacy userspace programs
written originally for other operating systems, and expect to get
high-performance results out of bad hardware decisions.

  There is no reason you have to do a cold reset to get your boot times
  down, there is the fun resume from a system image solution that
  others have done that can get that camera up and displayed in
  milliseconds.
  
 
 I'm interested in this point.
 - Are you talking about Save To RAM, Save to Disk, or a hybrid 
 combination of both?
 - Or do you have something completely different in mind?

A number of devices in the past have done a save system image to
flash, and then when starting up, just load the system image into memory
and jump into it, everything up and running with no startup time
needed other than the initial memory load.

When updating the system with new software, just be sure to write out a
new initial system state image at the same time, and you should be
fine for your next boot.

This idea / implementation has been around for a very long time, and has
shipped in lots of devices, solving the image in x seconds from power
on problem quite easily.

 I personally thought about such a solution as well. I'm by now not fully 
 convinced since we have really hard timing requirements (partly motivated by 
 law). So I see two different principal ways for a resume solution:
 - either the resume solution is robust enough to guarantee to come up 
 properly every boot up
   - achieved for instance by a static system image that brings the system 
 into a static state very fast, from which on a kind of conventional boot is 
 going on then ...

This is the easiest to do.

 - or the boot up after an actual cold reset is fast enough to at least 
 guarantee the really important timing requirements in case the resume is not 
 coming up properly

If you have good hardware, do this, but odds are, your hardware can't do
this, otherwise we wouldn't be having this whole conversation :)

   - Some modules do time / CPU consuming things in init(), which would
   delay the entry time into userspace
  
  Then fix them, that's the best thing about Linux, you have the source
  to not accept problems like this!  And no module should do expensive
  things in init(), we have been fixing issues like that for a while now.
  
 
 This would be properly the cleanest solution. 

[systemd-devel] [PATCH] util: fix strict aliasing violations in use of struct inotify_event v5

2014-12-23 Thread Shawn Paul Landden
There is alot of cleanup that will have to happen to turn on
-fstrict-aliasing, but I think our code should be correct to the rule.
---
 src/core/mount.c |  4 ++--
 src/core/path.c  |  4 ++--
 src/journal/sd-journal.c |  4 ++--
 src/shared/util.c|  5 ++---
 src/shared/util.h| 10 --
 src/udev/udevd.c |  4 ++--
 6 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index f8731bb..18ee2a0 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1701,11 +1701,11 @@ static int mount_dispatch_io(sd_event_source *source, 
int fd, uint32_t revents,
  * internal behaviour of libmount here. */
 
 for (;;) {
-uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
inotify_event);
+inotify_event_buffer_t buffer;
 struct inotify_event *e;
 ssize_t l;
 
-l = read(fd, buffer, sizeof(buffer));
+l = read(fd, buffer.raw, sizeof(buffer.raw));
 if (l  0) {
 if (errno == EAGAIN || errno == EINTR)
 break;
diff --git a/src/core/path.c b/src/core/path.c
index 656ed69..bc34f66 100644
--- a/src/core/path.c
+++ b/src/core/path.c
@@ -157,7 +157,7 @@ void path_spec_unwatch(PathSpec *s) {
 }
 
 int path_spec_fd_event(PathSpec *s, uint32_t revents) {
-uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct inotify_event);
+inotify_event_buffer_t buffer;
 struct inotify_event *e;
 ssize_t l;
 int r = 0;
@@ -167,7 +167,7 @@ int path_spec_fd_event(PathSpec *s, uint32_t revents) {
 return -EINVAL;
 }
 
-l = read(s-inotify_fd, buffer, sizeof(buffer));
+l = read(s-inotify_fd, buffer.raw, sizeof(buffer.raw));
 if (l  0) {
 if (errno == EAGAIN || errno == EINTR)
 return 0;
diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index d46dc3c..5f65116 100644
--- a/src/journal/sd-journal.c
+++ b/src/journal/sd-journal.c
@@ -2188,11 +2188,11 @@ _public_ int sd_journal_process(sd_journal *j) {
 j-last_process_usec = now(CLOCK_MONOTONIC);
 
 for (;;) {
-uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
inotify_event);
+inotify_event_buffer_t buffer;
 struct inotify_event *e;
 ssize_t l;
 
-l = read(j-inotify_fd, buffer, sizeof(buffer));
+l = read(j-inotify_fd, buffer.raw, sizeof(buffer.raw));
 if (l  0) {
 if (errno == EAGAIN || errno == EINTR)
 return got_something ? determine_change(j) : 
SD_JOURNAL_NOP;
diff --git a/src/shared/util.c b/src/shared/util.c
index 06b6077..2fbcdab 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -39,7 +39,6 @@
 #include linux/tiocl.h
 #include termios.h
 #include stdarg.h
-#include sys/inotify.h
 #include sys/poll.h
 #include ctype.h
 #include sys/prctl.h
@@ -2106,7 +2105,7 @@ int acquire_terminal(
 assert(notify = 0);
 
 for (;;) {
-uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
inotify_event);
+inotify_event_buffer_t buffer;
 struct inotify_event *e;
 ssize_t l;
 
@@ -2129,7 +2128,7 @@ int acquire_terminal(
 }
 }
 
-l = read(notify, buffer, sizeof(buffer));
+l = read(notify, buffer.raw, sizeof(buffer.raw));
 if (l  0) {
 if (errno == EINTR || errno == EAGAIN)
 continue;
diff --git a/src/shared/util.h b/src/shared/util.h
index 1804b8c..e9af32a 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -42,6 +42,7 @@
 #include locale.h
 #include mntent.h
 #include sys/socket.h
+#include sys/inotify.h
 
 #if SIZEOF_PID_T == 4
 #  define PID_FMT % PRIu32
@@ -1047,8 +1048,13 @@ int sethostname_idempotent(const char *s);
 #define INOTIFY_EVENT_MAX (sizeof(struct inotify_event) + NAME_MAX + 1)
 
 #define FOREACH_INOTIFY_EVENT(e, buffer, sz) \
-for ((e) = (struct inotify_event*) (buffer);\
- (uint8_t*) (e)  (uint8_t*) (buffer) + (sz); \
+for ((e) = (struct inotify_event*) (buffer.ev);\
+ (uint8_t*) (e)  (uint8_t*) (buffer.raw) + (sz); \
  (e) = (struct inotify_event*) ((uint8_t*) (e) + sizeof(struct 
inotify_event) + (e)-len))
 
+typedef union {
+struct inotify_event ev;
+uint8_t raw[INOTIFY_EVENT_MAX];
+} inotify_event_buffer_t;
+
 #define laccess(path, mode) faccessat(AT_FDCWD, (path), (mode), 
AT_SYMLINK_NOFOLLOW)
diff --git a/src/udev/udevd.c 

[systemd-devel] [PATCHv2] test: do not use last cap from kernel in test-cap-list

2014-12-23 Thread Filipe Brandenburger
The new test-cap-list introduced in commit 2822da4fb7f891 uses the included
table of capabilities. However, it uses cap_last_cap() which probes the kernel
for the last available capability. On an older kernel (e.g. 3.10 from RHEL 7)
that causes the test to fail with the following message:

Assertion '!capability_to_name(cap_last_cap()+1)' failed at 
src/test/test-cap-list.c:30, function main(). Aborting.

Fix it by exporting the size of the static table and using it in the test
instead of the dynamic one from the current kernel.

Tested by successfully running ./test-cap-list and the whole `make check` test
suite with this patch on a RHEL 7 host.
---
v2: Updated the patch to also consider the changes introduced in commit
4b7c1d5d6a0060 (test-cap-list: always check libcap comes to the same names...)

 src/shared/cap-list.c| 4 
 src/shared/cap-list.h| 1 +
 src/test/test-cap-list.c | 7 ---
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/shared/cap-list.c b/src/shared/cap-list.c
index 56d1488..8033e8c 100644
--- a/src/shared/cap-list.c
+++ b/src/shared/cap-list.c
@@ -60,3 +60,7 @@ int capability_from_name(const char *name) {
 
 return sc-id;
 }
+
+int capability_list_length(void) {
+return (int) ELEMENTSOF(capability_names);
+}
diff --git a/src/shared/cap-list.h b/src/shared/cap-list.h
index c699e46..9824fad 100644
--- a/src/shared/cap-list.h
+++ b/src/shared/cap-list.h
@@ -23,3 +23,4 @@
 
 const char *capability_to_name(int id);
 int capability_from_name(const char *name);
+int capability_list_length(void);
diff --git a/src/test/test-cap-list.c b/src/test/test-cap-list.c
index 7c5ae18..4e75136 100644
--- a/src/test/test-cap-list.c
+++ b/src/test/test-cap-list.c
@@ -19,6 +19,7 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
+#include util.h
 #include log.h
 #include cap-list.h
 #include capability.h
@@ -27,9 +28,9 @@ int main(int argc, char *argv[]) {
 int i;
 
 assert_se(!capability_to_name(-1));
-assert_se(!capability_to_name(cap_last_cap()+1));
+assert_se(!capability_to_name(capability_list_length()));
 
-for (i = 0; i = (int) cap_last_cap(); i++) {
+for (i = 0; i  capability_list_length(); i++) {
 const char *n;
 
 assert_se(n = capability_to_name(i));
@@ -45,7 +46,7 @@ int main(int argc, char *argv[]) {
 assert_se(capability_from_name(15) == 15);
 assert_se(capability_from_name(-1) == -EINVAL);
 
-for (i = 0; i = (int) cap_last_cap(); i++) {
+for (i = 0; i  capability_list_length(); i++) {
 _cleanup_cap_free_charp_ char *a = NULL;
 const char *b;
 unsigned u;
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-gpt-auto-generator does not appear to remount rootfs rw

2014-12-23 Thread Lennart Poettering
On Tue, 23.12.14 16:56, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

Heya,

 I'm using systemd 218 (stock upstream, unpatched)  dracut 040 (stock
 upstream, unpatched).
 
 I'm trying to build a basic GPT disk image to boot in a VM with
 gpt-auto-generator discovery of partitions.
 
 I create three partitions: ESP, swap and rootfs with the following type ids 
 set:
 sgdisk /dev/loop6 --typecode=1:c12a7328-f81f-11d2-ba4b-00a0c93ec93b
 sgdisk /dev/loop6 --typecode=2:0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
 sgdisk /dev/loop6 --typecode=3:4f68bce3-e8cd-4db1-96e7-fbcaf984b709
 
 In addition to that I clear the no-auto-mount and read-only attributes:
 sgdisk /dev/loop6 --attributes=1:clear:60
 sgdisk /dev/loop6 --attributes=1:clear:63
 sgdisk /dev/loop6 --attributes=3:clear:60
 sgdisk /dev/loop6 --attributes=3:clear:63
 
 Thus I am expecting for the gpt-auto-generator to work correctly.
 
 It does boot with and without initramfs, however in such configuration
 the root filesystem (3rd partition in this case) is mounted read-only
 and a few of standard systemd units fail. As per documentation, I had
 the impression that rootfs should be mounted read-write in such
 configuration.
 
 To mitigated this problem I came up with two workarounds:
 * add rw to the kernel cmdline
 * add /etc/fstab with a single entry like this one:
 /dev/gpt-auto-root / none   defaults,rw
 
 Is this correct additional requirements to get rw rootfs? Or is
 there a bug, and either of the workarounds are not required? Or are my
 type ids/attributes set wrongly on the partitions?

Humm, yeah. I remember thinking about this for a long time when I
hacked this up. The way this currently works is that the auto
discovery picks good defaults for the read-only flag, depending on
the partition, but allows the kernel cmdline to override it (for the
rootfs), as well as the gpt flag (for /srv and /home).

/home and /srv are hence writable by default, and the rootfs read-only
(simply under the assumption that that would be the better default in
the end). With the gpt partition flag you can make /home and /srv
read-only. And with rw on the kernel cmdline you can make /
writable. (Either can be overriden in /etc/fstab also).

Now, I think this behaviour makes some sense, but I am open to
suggestions to change things here if you can make a case. 

This all is admittedly a departure from the kernel's own mount logic
where ro is opt-in for the root fs, not opt-out...

Maybe one option would be to upgrade the read-only gpt flag to a
tri-state. Instead of just read-only and not read-only, it could
then be: read-only, writable, default. 

Turning the flag into a tri-state should be easy and be possible in a
compatible way, by just defining a new bit in the flag set.

Would that make sense for you?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] hwdb: add rule and first entry for PS/2 mice

2014-12-23 Thread Peter Hutterer
On Tue, Dec 23, 2014 at 02:16:15PM +0100, David Herrmann wrote:
 (CC'ing sd-devel this time.. sorry)
 
 On Tue, Dec 23, 2014 at 1:19 AM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  https://bugs.freedesktop.org/show_bug.cgi?id=87037
  ---
  some feedback on the rule would be appreciated, in case there's a better
  approach to matching.
 
   hwdb/70-mouse.hwdb   | 4 
   rules/70-mouse.rules | 3 +++
   2 files changed, 7 insertions(+)
 
  diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
  index d40e864..76bcf9b 100644
  --- a/hwdb/70-mouse.hwdb
  +++ b/hwdb/70-mouse.hwdb
  @@ -188,6 +188,10 @@ mouse:usb:v046dpc52b:name:Logitech Unifying Device. 
  Wireless PID:4026:
   mouse:bluetooth:v046dpb00d:name:Ultrathin Touch Mouse:
MOUSE_DPI=1000@1000
 
  +# ImExPS/2 Logitech Wheel Mouse
  +mouse:ps2:*:name:ImExPS/2 Logitech Wheel Mouse:
  + MOUSE_DPI=400@250
  +
   ##
   # Microsoft
   ##
  diff --git a/rules/70-mouse.rules b/rules/70-mouse.rules
  index 0e359e8..4e2eb8a 100644
  --- a/rules/70-mouse.rules
  +++ b/rules/70-mouse.rules
  @@ -11,5 +11,8 @@ KERNELS==input*, ENV{ID_BUS}==usb, \
   KERNELS==input*, ENV{ID_BUS}==bluetooth, \
   IMPORT{builtin}=hwdb 
  'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:',
   \
   GOTO=mouse_end
  +DRIVERS==psmouse, \
  +IMPORT{builtin}=hwdb 'mouse:ps2::name:$attr{device/name}:', \
  +GOTO=mouse_end
 
 So 'psmouse' uses:
 %s %s %s, protocol, vendor, name
 
 Kinda disappointing that we cannot query each value individually.. but
 it's 80's technology, so I guess no-one cares that much, anyway.
 
 I'm fine with matching on the driver, but I'd prefer adding a
 SUBSYSTEMS==serio (or even SUBSYSTEM? not sure, don't have a ps2
 device here).

added SUBSYSTEMS. fwiw, SUBSYSTEM on the actual device is 'input', bug 87037
has the udevadm output but I found the trackstick on the lenovos looks
almost identical for testing.

 So please, go ahead and push it.

done, thanks. 

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] util: fix strict aliasing violations in use of struct inotify_event v5

2014-12-23 Thread Lennart Poettering
On Tue, 23.12.14 13:47, Shawn Paul Landden (sh...@churchofgit.com) wrote:

 There is alot of cleanup that will have to happen to turn on
 -fstrict-aliasing, but I think our code should be correct to the
 rule.

Applied with some minor changes! (we try to use _t only for things
that actually feel like types, you'd pass around via call-by-value,
not call-by-ref...)

Thanks!

 ---
  src/core/mount.c |  4 ++--
  src/core/path.c  |  4 ++--
  src/journal/sd-journal.c |  4 ++--
  src/shared/util.c|  5 ++---
  src/shared/util.h| 10 --
  src/udev/udevd.c |  4 ++--
  6 files changed, 18 insertions(+), 13 deletions(-)
 
 diff --git a/src/core/mount.c b/src/core/mount.c
 index f8731bb..18ee2a0 100644
 --- a/src/core/mount.c
 +++ b/src/core/mount.c
 @@ -1701,11 +1701,11 @@ static int mount_dispatch_io(sd_event_source *source, 
 int fd, uint32_t revents,
   * internal behaviour of libmount here. */
  
  for (;;) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
 inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 -l = read(fd, buffer, sizeof(buffer));
 +l = read(fd, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EAGAIN || errno == EINTR)
  break;
 diff --git a/src/core/path.c b/src/core/path.c
 index 656ed69..bc34f66 100644
 --- a/src/core/path.c
 +++ b/src/core/path.c
 @@ -157,7 +157,7 @@ void path_spec_unwatch(PathSpec *s) {
  }
  
  int path_spec_fd_event(PathSpec *s, uint32_t revents) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  int r = 0;
 @@ -167,7 +167,7 @@ int path_spec_fd_event(PathSpec *s, uint32_t revents) {
  return -EINVAL;
  }
  
 -l = read(s-inotify_fd, buffer, sizeof(buffer));
 +l = read(s-inotify_fd, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EAGAIN || errno == EINTR)
  return 0;
 diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
 index d46dc3c..5f65116 100644
 --- a/src/journal/sd-journal.c
 +++ b/src/journal/sd-journal.c
 @@ -2188,11 +2188,11 @@ _public_ int sd_journal_process(sd_journal *j) {
  j-last_process_usec = now(CLOCK_MONOTONIC);
  
  for (;;) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
 inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 -l = read(j-inotify_fd, buffer, sizeof(buffer));
 +l = read(j-inotify_fd, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EAGAIN || errno == EINTR)
  return got_something ? determine_change(j) : 
 SD_JOURNAL_NOP;
 diff --git a/src/shared/util.c b/src/shared/util.c
 index 06b6077..2fbcdab 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -39,7 +39,6 @@
  #include linux/tiocl.h
  #include termios.h
  #include stdarg.h
 -#include sys/inotify.h
  #include sys/poll.h
  #include ctype.h
  #include sys/prctl.h
 @@ -2106,7 +2105,7 @@ int acquire_terminal(
  assert(notify = 0);
  
  for (;;) {
 -uint8_t buffer[INOTIFY_EVENT_MAX] _alignas_(struct 
 inotify_event);
 +inotify_event_buffer_t buffer;
  struct inotify_event *e;
  ssize_t l;
  
 @@ -2129,7 +2128,7 @@ int acquire_terminal(
  }
  }
  
 -l = read(notify, buffer, sizeof(buffer));
 +l = read(notify, buffer.raw, sizeof(buffer.raw));
  if (l  0) {
  if (errno == EINTR || errno == EAGAIN)
  continue;
 diff --git a/src/shared/util.h b/src/shared/util.h
 index 1804b8c..e9af32a 100644
 --- a/src/shared/util.h
 +++ b/src/shared/util.h
 @@ -42,6 +42,7 @@
  #include locale.h
  #include mntent.h
  #include sys/socket.h
 +#include sys/inotify.h
  
  #if SIZEOF_PID_T == 4
  #  define PID_FMT % PRIu32
 @@ -1047,8 +1048,13 @@ int sethostname_idempotent(const char *s);
  #define INOTIFY_EVENT_MAX (sizeof(struct inotify_event) + NAME_MAX + 1)
  
  #define FOREACH_INOTIFY_EVENT(e, buffer, sz) \
 -for ((e) = (struct inotify_event*) (buffer);\
 - (uint8_t*) (e)  (uint8_t*) (buffer) + (sz); \
 +for ((e) = (struct inotify_event*) (buffer.ev);\
 + (uint8_t*) (e)  (uint8_t*) 

Re: [systemd-devel] [systemd-commits] 8 commits - Makefile.am TODO src/bus-proxyd src/core src/import src/libsystemd src/machine src/shared src/test

2014-12-23 Thread Lennart Poettering
On Tue, 23.12.14 11:13, Filipe Brandenburger (filbran...@google.com) wrote:

 Hi,
 
 On Tue, Dec 23, 2014 at 10:15 AM, Lennart Poettering
 lenn...@kemper.freedesktop.org wrote:
  commit 3c70e3bb022f0de3317f3600c9366a2f4597339e
  Author: Lennart Poettering lenn...@poettering.net
  Date:   Tue Dec 23 18:36:04 2014 +0100
 
  core: rearrange code so that libsystemd/sd-bus/ does not include header 
  files from core
 
  Stuff in src/shared or src/libsystemd should *never* include code from
  src/core or any of the tools, so don't do that here either. It's not OK!
 
 This commit broke the build, looks like src/core/bus-policy.[ch]
 should have been added to this commit but they were not...

Fixed! Thanks!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/3] machined: add org.freedesktop.machine1.policy.in to POTFILES.in

2014-12-23 Thread Filipe Brandenburger
The new polkit file was introduced in commit d04c1fb8e21560 (machined:
introduce polkit for OpenLogin() call).
---
 po/POTFILES.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 2829c87..344c307 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,5 +1,6 @@
 src/hostname/org.freedesktop.hostname1.policy.in
 src/locale/org.freedesktop.locale1.policy.in
 src/login/org.freedesktop.login1.policy.in
+src/machine/org.freedesktop.machine1.policy.in
 src/timedate/org.freedesktop.timedate1.policy.in
 src/core/org.freedesktop.systemd1.policy.in.in
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/3] build-sys: update path in reference to sd-lldp.h

2014-12-23 Thread Filipe Brandenburger
The file was moved from src/libsystemd-network to src/systemd in commit
7a6f1457462840 (sd-lldp: minor header cleanup).

This fixes make distcheck.
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 4173147..8446469 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3054,6 +3054,7 @@ libsystemd_network_la_SOURCES = \
src/systemd/sd-dhcp6-client.h \
src/systemd/sd-dhcp6-lease.h \
src/systemd/sd-pppoe.h \
+   src/systemd/sd-lldp.h \
src/libsystemd-network/sd-dhcp-client.c \
src/libsystemd-network/sd-dhcp-server.c \
src/libsystemd-network/dhcp-network.c \
@@ -3089,7 +3090,6 @@ libsystemd_network_la_SOURCES = \
src/libsystemd-network/lldp-internal.h \
src/libsystemd-network/lldp-internal.c \
src/libsystemd-network/lldp-util.h \
-   src/libsystemd-network/sd-lldp.h \
src/libsystemd-network/sd-lldp.c
 
 libsystemd_network_la_LIBADD = \
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/2] libudev: fix strict aliasing violation

2014-12-23 Thread Shawn Paul Landden
---
 src/libudev/libudev-monitor.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index e8d6b4a..484fefe 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -582,7 +582,10 @@ _public_ struct udev_device 
*udev_monitor_receive_device(struct udev_monitor *ud
 struct cmsghdr *cmsg;
 union sockaddr_union snl;
 struct ucred *cred;
-char buf[8192];
+union {
+struct udev_monitor_netlink_header nlh;
+char raw[8192];
+} buf;
 ssize_t buflen;
 ssize_t bufpos;
 
@@ -642,29 +645,26 @@ retry:
 if (udev_device == NULL)
 return NULL;
 
-if (memcmp(buf, libudev, 8) == 0) {
-struct udev_monitor_netlink_header *nlh;
-
+if (memcmp(buf.raw, libudev, 8) == 0) {
 /* udev message needs proper version magic */
-nlh = (struct udev_monitor_netlink_header *) buf;
-if (nlh-magic != htonl(UDEV_MONITOR_MAGIC)) {
+if (buf.nlh.magic != htonl(UDEV_MONITOR_MAGIC)) {
 log_debug(unrecognized message signature (%x != %x),
- nlh-magic, htonl(UDEV_MONITOR_MAGIC));
+ buf.nlh.magic, htonl(UDEV_MONITOR_MAGIC));
 udev_device_unref(udev_device);
 return NULL;
 }
-if (nlh-properties_off+32  (size_t)buflen) {
+if (buf.nlh.properties_off+32  (size_t)buflen) {
 udev_device_unref(udev_device);
 return NULL;
 }
 
-bufpos = nlh-properties_off;
+bufpos = buf.nlh.properties_off;
 
 /* devices received from udev are always initialized */
 udev_device_set_is_initialized(udev_device);
 } else {
 /* kernel message with header */
-bufpos = strlen(buf) + 1;
+bufpos = strlen(buf.raw) + 1;
 if ((size_t)bufpos  sizeof(a@/d) || bufpos = buflen) {
 log_debug(invalid message length);
 udev_device_unref(udev_device);
@@ -672,7 +672,7 @@ retry:
 }
 
 /* check message header */
-if (strstr(buf, @/) == NULL) {
+if (strstr(buf.raw, @/) == NULL) {
 log_debug(unrecognized message header);
 udev_device_unref(udev_device);
 return NULL;
@@ -685,7 +685,7 @@ retry:
 char *key;
 size_t keylen;
 
-key = buf[bufpos];
+key = buf.raw[bufpos];
 keylen = strlen(key);
 if (keylen == 0)
 break;
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/2] udev: fix another strict aliasing issue

2014-12-23 Thread Shawn Paul Landden
---
 src/udev/ata_id/ata_id.c | 62 +++-
 1 file changed, 30 insertions(+), 32 deletions(-)

diff --git a/src/udev/ata_id/ata_id.c b/src/udev/ata_id/ata_id.c
index 89628c9..fc13819 100644
--- a/src/udev/ata_id/ata_id.c
+++ b/src/udev/ata_id/ata_id.c
@@ -409,7 +409,11 @@ int main(int argc, char *argv[])
 {
 struct udev *udev;
 struct hd_driveid id;
-uint8_t identify[512];
+union {
+uint8_t  byte[512];
+uint16_t wyde[256];
+uint64_t octa[64];
+} identify;
 uint16_t *identify_words;
 char model[41];
 char model_enc[256];
@@ -467,30 +471,30 @@ int main(int argc, char *argv[])
 goto exit;
 }
 
-if (disk_identify(udev, fd, identify, is_packet_device) == 0) {
+if (disk_identify(udev, fd, identify.byte, is_packet_device) == 0) {
 /*
  * fix up only the fields from the IDENTIFY data that we are 
going to
  * use and copy it into the hd_driveid struct for convenience
  */
-disk_identify_fixup_string(identify,  10, 20); /* serial */
-disk_identify_fixup_string(identify,  23,  8); /* fwrev */
-disk_identify_fixup_string(identify,  27, 40); /* model */
-disk_identify_fixup_uint16(identify,  0);  /* 
configuration */
-disk_identify_fixup_uint16(identify,  75); /* queue depth 
*/
-disk_identify_fixup_uint16(identify,  75); /* SATA 
capabilities */
-disk_identify_fixup_uint16(identify,  82); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  83); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  84); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  85); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  86); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  87); /* command set 
supported */
-disk_identify_fixup_uint16(identify,  89); /* time 
required for SECURITY ERASE UNIT */
-disk_identify_fixup_uint16(identify,  90); /* time 
required for enhanced SECURITY ERASE UNIT */
-disk_identify_fixup_uint16(identify,  91); /* current APM 
values */
-disk_identify_fixup_uint16(identify,  94); /* current AAM 
value */
-disk_identify_fixup_uint16(identify, 128); /* device lock 
function */
-disk_identify_fixup_uint16(identify, 217); /* nominal 
media rotation rate */
-memcpy(id, identify, sizeof id);
+disk_identify_fixup_string(identify.byte,  10, 20); /* serial 
*/
+disk_identify_fixup_string(identify.byte,  23,  8); /* fwrev */
+disk_identify_fixup_string(identify.byte,  27, 40); /* model */
+disk_identify_fixup_uint16(identify.byte,  0);  /* 
configuration */
+disk_identify_fixup_uint16(identify.byte,  75); /* queue 
depth */
+disk_identify_fixup_uint16(identify.byte,  75); /* SATA 
capabilities */
+disk_identify_fixup_uint16(identify.byte,  82); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  83); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  84); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  85); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  86); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  87); /* command 
set supported */
+disk_identify_fixup_uint16(identify.byte,  89); /* time 
required for SECURITY ERASE UNIT */
+disk_identify_fixup_uint16(identify.byte,  90); /* time 
required for enhanced SECURITY ERASE UNIT */
+disk_identify_fixup_uint16(identify.byte,  91); /* current 
APM values */
+disk_identify_fixup_uint16(identify.byte,  94); /* current 
AAM value */
+disk_identify_fixup_uint16(identify.byte, 128); /* device 
lock function */
+disk_identify_fixup_uint16(identify.byte, 217); /* nominal 
media rotation rate */
+memcpy(id, identify.byte, sizeof id);
 } else {
 /* If this fails, then try HDIO_GET_IDENTITY */
 if (ioctl(fd, HDIO_GET_IDENTITY, id) != 0) {
@@ -499,7 +503,7 @@ int main(int argc, char *argv[])
 goto close;
 }
 }
-identify_words = (uint16_t *) identify;
+identify_words = identify.wyde;
 
 memcpy (model, 

[systemd-devel] How to write two .mount units for the same directory?

2014-12-23 Thread CUI Hao
Hi all,

I want to write 2 mount unit to mount the same directory. When the first
failed to mount, then the second is called via OnFailure= setting. (Think
of an NTFS partition after Windows' hiberation. I'd like to write a backup
unit to mount it readonly.)

But there is a rule that Where= setting must match unit name in a
.mount unit. This means only one unit can be created for one directory,
right?

Is there any way to achieve my idea, or it's just impossible? And what's
the necessity of this naming rule?

Thanks!

-- 
崔灏 / CUI Hao
Homepage: i-yu.me
Twitter: @cuihaoleo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-23 Thread Alison Chaiken
Marko Hoyer:
 Are you talking about Save To RAM, Save to Disk, or a hybrid combination 
 of both?  Or do you have something
 completely different in mind?

GKH:
A number of devices in the past have done a save system image to flash, and 
then when starting up, just load the
system image into memory and jump into it, everything up and running with no 
startup time needed other than the
initial memory load.

Not all processors currently support this behavior.   See Russ Dill's
talk at 2013 ELC,

Extending the swsusp Hibernation Framework to ARM,
http://elinux.org/images/0/0c/Slides.pdf

or, put differently, on x86 3.16,
$# cat /sys/power/state
freeze standby mem disk

On Cortex-A9 3.14:
$# cat /sys/power/state
freeze mem

Dill's work added hibernation support for AM33xx.My understanding
of his presentation is that hibernation is not fully implemented for
other ARM processors.

On another topic that came up in this thread, why does
systemd-udev-settle.service exist?Doesn't the execution of this
service imply a synchronization point, and doesn't systemd create
targets rather than services for this purpose?   Wouldn't
systemd-udev-settle.target make more sense then?

Tom Gundersen:
In a stock Fedora/Arch (and probably others, but didn't check)
systemd-modules-load is not used at all.
[ . . . ]
I'm not aware of any kernel modules that legitimately needs to be
loaded in this way (i.e., all the ones that do can/should be fixed).

On my Debian Testing system, I see fuse, loop, lp, ppdev and
parport_pc.   The last 3 are related to printing, and presumably must
be preloaded because some printers will not usefully identify
themselves when powered on.   Giving unsophisticated users access to a
wide variety of hotplugged devices is undoubtedly the main reasons
distros want to use systemd-modules-load.

Marko Hoyer:
We are not using systemd-modules-load for applying this approach since it is 
trying to load all modules in one shot.

Can systemd units list kernel modules as explicit dependencies?   If
so, systemd's usual methods for ordering the start of units can
influence the loading order of modules.

Marko Hoyer:
- we have heavy graphics drivers (~800kb, stripped), they are needed 
 half the way at startup
- video processing unit drivers (don't know the size), they are needed 
 half the way at startup
- wireless  bluetooth, they are needed very late
- usb subsystem, conventionally needed very late (but this finally 
 depends on the concrete product)
- hot plug mass storage handling, conventionally needed very late (but 
 this finally depends on the concrete product)
- audio driver, in most of our products needed very late
- some drivers for INC communication (partly needed very early - we 
 compiled in them, partly needed later - we have them as module)

Consider that wireless, bluetooth, audio and hotplug mass storage have
the modules on which they rely as systemd Requisites in their unit
files.   We put the units for theseservices into a connectivity.target
that comes After a render.target that the graphics, video and INC are
in.   render.target then has as Requisites the GPU, VPU and INC
modules.   When each of these targets is started, the units could
insmod the modules and just skip udev rules altogether.   These
dependencies won't prevent the kernel from trying to load the later
modules sooner, but insmod'ing earlier needed modules explicitly will
still influence the order.

-- Alison Chaiken,
Mentor Graphics

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel