[systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined

2013-08-07 Thread Maarten Lankhorst 
Op 07-08-13 02:26, Andy Lutomirski schreef:
 On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen t...@jklm.no wrote:
 On 6 Aug 2013 18:32, Bryan Kadzban br...@kadzban.is-a-geek.net wrote:
 On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote:
 On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen t...@jklm.no wrote:
 On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst
 m.b.lankho...@gmail.com wrote:
 Op 05-08-13 18:29, Andy Lutomirski schreef:
 The systemd commit below can delay firmware loading by multiple
 minutes if CONFIG_FW_LOADER_USER_HELPER=y.  Unfortunately no one
 noticed that the systemd-udev change would break new kernels as well
 as old kernels.

 Since the kernel apparently can't count on reasonable userspace
 support, turn this thing off by default.

 commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
 Author: Tom Gundersen t...@jklm.no
 Date:   Mon Mar 18 15:12:18 2013 +0100

 udev: make firmware loading optional and disable by default

 Distros that whish to support old kernels should set

 --with-firmware-dirs=/usr/lib/firmware/updates:/usr/lib/firmware
 to retain the old behaviour.

 methinks this patch should be reverted then,
 Well, all the code is still there, so it can be enabled if anyone
 wants it.

 or a stub should be added to udev to always fail firmware loading so
 timeouts don't occur.
 I think the only use (if any) of a userspace firmware loader would be
 for anyone who wants a custom one (i.e., not udev), so we shouldn't
 just fail the loading from udev unconditionally.

 How about we just improve the udev documentation a bit, similar to
 Andy's kernel patch?
 Sorry, I should first have checked. We already document this in the
 README:

Userspace firmware loading is deprecated, will go away, and
sometimes causes problems:
  CONFIG_FW_LOADER_USER_HELPER=n
 ...And this patch is making the kernel default to the correct behavior,
 instead of the now-broken-by-udev behavior.

 I'm not sure I see the issue with it?  :-)
 Oh yeah this patch is totally the right thing to do, I was just arguing that
 there is nothing to be done on the udev side.

 (Add me to the list of people that think udev is broken too, fwiw.  But
 let's at least not leave *both* sides in a broken-by-default state.)
 Well I don't think it is too much to ask that the kernel and udev should be
 configured in a consistent way. Especially as thing still work even if you
 get it wrong, albeit with a delay.
 Except that the current defaults are inconsistent and there is no
 explanation anywhere in the logs when this is screwed up.

So what is wrong with my 'fail in udev immediately if not configured' idea? In 
that case it
doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not.

You could even print a useful message for the user in udev to the log, so they 
have an idea of what
happened. Breaking udev on older still supported kernels by default without 
printing any debug info
is silly, and the only cost is a small increase in disk space when unused. I 
did so in below patch.

~Maarten

I converted  ELEMENTSOF to != ELEMENTSOF in the loop to work correctly when 
the array is empty.
Most code in udev-builtin-firmware is eliminated at -O2 optimization level when 
FIRMWARE_PATH
is not explicitly set.

8
diff --git a/Makefile.am b/Makefile.am
index b8b8d06..2097629 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2235,6 +2235,7 @@ libudev_core_la_SOURCES = \
src/udev/udev-ctrl.c \
src/udev/udev-builtin.c \
src/udev/udev-builtin-btrfs.c \
+   src/udev/udev-builtin-firmware.c \
src/udev/udev-builtin-hwdb.c \
src/udev/udev-builtin-input_id.c \
src/udev/udev-builtin-keyboard.c \
@@ -2271,14 +2272,6 @@ libudev_core_la_CPPFLAGS = \
$(AM_CPPFLAGS) \
-DFIRMWARE_PATH=$(FIRMWARE_PATH)
 
-if ENABLE_FIRMWARE
-libudev_core_la_SOURCES += \
-   src/udev/udev-builtin-firmware.c
-
-dist_udevrules_DATA += \
-   rules/50-firmware.rules
-endif
-
 if HAVE_KMOD
 libudev_core_la_SOURCES += \
src/udev/udev-builtin-kmod.c
diff --git a/configure.ac b/configure.ac
index 0ecc716..dc7a3e3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -823,8 +823,6 @@ for i in $with_firmware_path; do
 done
 IFS=$OLD_IFS
 AC_SUBST(FIRMWARE_PATH)
-AS_IF([test x${FIRMWARE_PATH} != x], [ AC_DEFINE(HAVE_FIRMWARE, 1, [Define 
if FIRMWARE is available]) ])
-AM_CONDITIONAL(ENABLE_FIRMWARE, [test x${FIRMWARE_PATH} != x])
 
 # 
--
 AC_ARG_ENABLE([gudev],
diff --git a/rules/50-firmware.rules b/rules/50-firmware.rules
deleted file mode 100644
index f0ae684..000
--- a/rules/50-firmware.rules
+++ /dev/null
@@ -1,3 +0,0 @@
-# do not edit this file, it will be overwritten on update
-
-SUBSYSTEM==firmware, ACTION==add, RUN{builtin}=firmware
diff --git a/rules/50-udev-default.rules b/rules/50-udev-default.rules
index f764789..645830e 100644
--- a/rules/50-udev-default.rules
+++

[systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?

2013-08-07 Thread Mathijs Kwik 
Hi all,

I have a few things that need to get run after waking up my laptop
(things like hdparm to set device power options/spindown time).
I created oneshot, remainafterexit services for those and made them
wanted by multi-user.target.This works fine for the first boot.

As I consider these services dead after a suspend/hibernate, I added
Conflicts=sleep.target, so now systemd is aware that these services
are no longer active after a wakeup.

Now I would like to somehow have these services restart on wakeup.
I can add these services to some new target(wakeup.target), but I
don't know how to proceed from there. I thought of making
wakeup.target WantedBy suspend.target, After suspend.target, but since
suspend.target pulls in sleep.target (which conflicts with these
services) that will fail. More so, after wakeup.target is started the
first time, it will never go down itself, so the second wakeup won't
do anything. The same is true for multi-user.target, once that is
reached/activated on first boot, it never deactivates until shutdown.

How should a situation like this be handled?
Ideally, I don't want to use:
- /usr/lib/systemd/system-sleep  (considered hacky)
- a service/script that runs systemctl start ...  (secret
dependency, hidden from systemd)

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

Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?

2013-08-07 Thread Tom Gundersen 
On Wed, Aug 7, 2013 at 10:12 AM, Mathijs Kwik math...@bluescreen303.nl wrote:
 I have a few things that need to get run after waking up my laptop
 (things like hdparm to set device power options/spindown time).
 I created oneshot, remainafterexit services for those and made them
 wanted by multi-user.target.This works fine for the first boot.

Are you sure you want RemainAfterExit? Without it you should be able
to set WantedBy=sleep.target and After=sleep.target.

 As I consider these services dead after a suspend/hibernate, I added
 Conflicts=sleep.target, so now systemd is aware that these services
 are no longer active after a wakeup.

 Now I would like to somehow have these services restart on wakeup.
 I can add these services to some new target(wakeup.target), but I
 don't know how to proceed from there. I thought of making
 wakeup.target WantedBy suspend.target, After suspend.target, but since
 suspend.target pulls in sleep.target (which conflicts with these
 services) that will fail. More so, after wakeup.target is started the
 first time, it will never go down itself, so the second wakeup won't
 do anything. The same is true for multi-user.target, once that is
 reached/activated on first boot, it never deactivates until shutdown.

 How should a situation like this be handled?
 Ideally, I don't want to use:
 - /usr/lib/systemd/system-sleep  (considered hacky)
 - a service/script that runs systemctl start ...  (secret
 dependency, hidden from systemd)

 Thanks,
 Mathijs
 ___
 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

[systemd-devel] Impact when not loading ipv6 and autofs kernel module ...

2013-08-07 Thread Hoyer, Marko (ADITG/SW2) 
Hello systemd developers,

I found that systemd automatically tries to load ipv6 and autofs kernel 
modules, when they are not compiled in.
Could you give me a hint what is not working, when they are neither provided as 
kernel modules nor compiled in?

In case of autofs I found that automount units are not working any more (I 
would have expected this). Without ipv6 I can't find any problems by now.

So:


1.   Is there any other impact but the described one when the autofs kernel 
feature is missing?

2.   What impact do I have to expect in case the kernel does not provide 
ipv6 functionality?


Thx for any input.

Best regards

Marko Hoyer
Advanced Driver Information Technology GmbH
Software Group II (ADITG/SW2)
Robert-Bosch-Str. 200
31139 Hildesheim
Germany
Tel. +49 5121 49 6948
Fax +49 5121 49 6999
mho...@de.adit-jv.com
ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car 
Multimedia GmbH and DENSO Corporation
Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
Geschäftsführung: Wilhelm Grabow, Katsuyoshi Maeda
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Impact when not loading ipv6 and autofs kernel module ...

2013-08-07 Thread Tom Gundersen 
On Wed, Aug 7, 2013 at 1:24 PM, Hoyer, Marko (ADITG/SW2)
mho...@de.adit-jv.com wrote:
 2.   What impact do I have to expect in case the kernel does not provide
 ipv6 functionality?

I think the main problem is in case you were to somehow insmod the
ipv6 module after boot, in which case it probably won't be set up
correctly. Maybe someone else know of other problems?

Cheers,

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

Re: [systemd-devel] [PATCH v2, ping?] tmpfiles, man: Add xattr support to tmpfiles

2013-08-07 Thread Łukasz Stelmach 
It was 2013-07-15 pon 15:22, when Maciej Wereski wrote:
 diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
 index 519f9bc..92157b5 100644
 --- a/man/tmpfiles.d.xml
 +++ b/man/tmpfiles.d.xml
 @@ -229,6 +229,21 @@ L/tmp/foobar ----   
 /dev/null/programlisting
  place of normal path
  names./para/listitem
  /varlistentry
 +
 +varlistentry
 +termvarnamet/varname/term
 +listitemparaSet extended
 +attributes on item. It should be
 +used with conjunction with other

in conjunction with

-- 
Łukasz Stelmach
Samsung RD Institute Poland
Samsung Electronics
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-08-07 Thread Tony Seo 
 Hello.

Now, I have studied systemd for optimizing systemd on my board.

After edited several units, I would like to delete some device
configuration units existing on my picture from
systemd-analyze(best-dream-boy.blogspot)

I read the manual pages about systemd.device, I tried to delete device
units through editing /etc/fstab and systemctl mask.

But I couldn't delete those device units, at least existing units on the
picture.

So I would ask you a question about it.


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

Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-08-07 Thread Mantas Mikulėnas 
On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo tonys...@gmail.com wrote:

  Hello.

 Now, I have studied systemd for optimizing systemd on my board.

 After edited several units, I would like to delete some device configuration
 units existing on my picture from systemd-analyze(best-dream-boy.blogspot)

 I read the manual pages about systemd.device, I tried to delete device units
 through editing /etc/fstab and systemctl mask.

 But I couldn't delete those device units, at least existing units on the
 picture.

You cannot delete these units because they do not exist anywhere
except in memory – they're only a way to represent device status in
the format of systemd units. In other words, they do not cause the
problems you're having; they only make the problems visible in your
bootchart.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined

2013-08-07 Thread Andy Lutomirski 
On Wed, Aug 7, 2013 at 12:52 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
 Op 07-08-13 02:26, Andy Lutomirski schreef:
 On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen t...@jklm.no wrote:
 On 6 Aug 2013 18:32, Bryan Kadzban br...@kadzban.is-a-geek.net wrote:
 On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote:
 On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen t...@jklm.no wrote:
 On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst
 m.b.lankho...@gmail.com wrote:
 Op 05-08-13 18:29, Andy Lutomirski schreef:
 The systemd commit below can delay firmware loading by multiple
 minutes if CONFIG_FW_LOADER_USER_HELPER=y.  Unfortunately no one
 noticed that the systemd-udev change would break new kernels as well
 as old kernels.

 Since the kernel apparently can't count on reasonable userspace
 support, turn this thing off by default.

 commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
 Author: Tom Gundersen t...@jklm.no
 Date:   Mon Mar 18 15:12:18 2013 +0100

 udev: make firmware loading optional and disable by default

 Distros that whish to support old kernels should set

 --with-firmware-dirs=/usr/lib/firmware/updates:/usr/lib/firmware
 to retain the old behaviour.

 methinks this patch should be reverted then,
 Well, all the code is still there, so it can be enabled if anyone
 wants it.

 or a stub should be added to udev to always fail firmware loading so
 timeouts don't occur.
 I think the only use (if any) of a userspace firmware loader would be
 for anyone who wants a custom one (i.e., not udev), so we shouldn't
 just fail the loading from udev unconditionally.

 How about we just improve the udev documentation a bit, similar to
 Andy's kernel patch?
 Sorry, I should first have checked. We already document this in the
 README:

Userspace firmware loading is deprecated, will go away, and
sometimes causes problems:
  CONFIG_FW_LOADER_USER_HELPER=n
 ...And this patch is making the kernel default to the correct behavior,
 instead of the now-broken-by-udev behavior.

 I'm not sure I see the issue with it?  :-)
 Oh yeah this patch is totally the right thing to do, I was just arguing that
 there is nothing to be done on the udev side.

 (Add me to the list of people that think udev is broken too, fwiw.  But
 let's at least not leave *both* sides in a broken-by-default state.)
 Well I don't think it is too much to ask that the kernel and udev should be
 configured in a consistent way. Especially as thing still work even if you
 get it wrong, albeit with a delay.
 Except that the current defaults are inconsistent and there is no
 explanation anywhere in the logs when this is screwed up.

 So what is wrong with my 'fail in udev immediately if not configured' idea? 
 In that case it
 doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not.

 You could even print a useful message for the user in udev to the log, so 
 they have an idea of what
 happened. Breaking udev on older still supported kernels by default without 
 printing any debug info
 is silly, and the only cost is a small increase in disk space when unused. I 
 did so in below patch.

Seems reasonable to me.  It might be worth adding something to the
message to suggest turning off CONFIG_FW_LOADER_USER_HELPER.


 ~Maarten

 I converted  ELEMENTSOF to != ELEMENTSOF in the loop to work correctly when 
 the array is empty.
 Most code in udev-builtin-firmware is eliminated at -O2 optimization level 
 when FIRMWARE_PATH
 is not explicitly set.

 8
 diff --git a/Makefile.am b/Makefile.am
 index b8b8d06..2097629 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -2235,6 +2235,7 @@ libudev_core_la_SOURCES = \
 src/udev/udev-ctrl.c \
 src/udev/udev-builtin.c \
 src/udev/udev-builtin-btrfs.c \
 +   src/udev/udev-builtin-firmware.c \
 src/udev/udev-builtin-hwdb.c \
 src/udev/udev-builtin-input_id.c \
 src/udev/udev-builtin-keyboard.c \
 @@ -2271,14 +2272,6 @@ libudev_core_la_CPPFLAGS = \
 $(AM_CPPFLAGS) \
 -DFIRMWARE_PATH=$(FIRMWARE_PATH)

 -if ENABLE_FIRMWARE
 -libudev_core_la_SOURCES += \
 -   src/udev/udev-builtin-firmware.c
 -
 -dist_udevrules_DATA += \
 -   rules/50-firmware.rules
 -endif
 -
  if HAVE_KMOD
  libudev_core_la_SOURCES += \
 src/udev/udev-builtin-kmod.c
 diff --git a/configure.ac b/configure.ac
 index 0ecc716..dc7a3e3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -823,8 +823,6 @@ for i in $with_firmware_path; do
  done
  IFS=$OLD_IFS
  AC_SUBST(FIRMWARE_PATH)
 -AS_IF([test x${FIRMWARE_PATH} != x], [ AC_DEFINE(HAVE_FIRMWARE, 1, 
 [Define if FIRMWARE is available]) ])
 -AM_CONDITIONAL(ENABLE_FIRMWARE, [test x${FIRMWARE_PATH} != x])

  # 
 --
  AC_ARG_ENABLE([gudev],
 diff --git a/rules/50-firmware.rules b/rules/50-firmware.rules
 deleted file mode 100644
 index f0ae684..000
 --- a/rules/50-firmware.rules
 +++ /dev/null
 @@

[systemd-devel] [Re] I wanna construct server-client model with systemd option

2013-08-07 Thread Tony Seo 
 Thank you for your friendly answer.

 After I recevied your mail, I have aimed to complete to make server-client
model.

 In my view, I didn't still know how to use a service option in service
configuration file.

 The seceario I want to make is like this:


  *A..service is a server program and it should be remained continuously.*

 *And B.service as a client program can access to A.service which
has been living in systemd.*



In this case, What should I use options  each service which I said.


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

Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-08-07 Thread Tony Seo 
 I understand what you mean, but I think that I will cut the time for
loading device unit if I keep those from appearing on my plot.

 I want to do a try to temporarily disappear some kinds of device units and
then I'm supposed to measure boot speed depending a board of
mine.(Actually, I believe that loading time for device unit affects to boot
speed)

 What do think that loading time for device units doesn't affect to boot
speed at machine?

 Thanks.



2013/8/8 Mantas Mikulėnas graw...@gmail.com

 On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo tonys...@gmail.com wrote:
 
   Hello.
 
  Now, I have studied systemd for optimizing systemd on my board.
 
  After edited several units, I would like to delete some device
 configuration
  units existing on my picture from
 systemd-analyze(best-dream-boy.blogspot)
 
  I read the manual pages about systemd.device, I tried to delete device
 units
  through editing /etc/fstab and systemctl mask.
 
  But I couldn't delete those device units, at least existing units on the
  picture.

 You cannot delete these units because they do not exist anywhere
 except in memory – they're only a way to represent device status in
 the format of systemd units. In other words, they do not cause the
 problems you're having; they only make the problems visible in your
 bootchart.

 --
 Mantas Mikulėnas graw...@gmail.com

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

Re: [systemd-devel] [PATCH] dbus: use _cleanup_free_ instead of freeing ourself

2013-08-07 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Jul 25, 2013 at 05:36:01PM +0200, Ronny Chevalier wrote:
 ---
  src/core/dbus-execute.c |  3 +--
  src/core/dbus-job.c | 11 ++-
  src/core/dbus-manager.c | 14 +++---
  src/core/unit.c | 48 ++--
  4 files changed, 28 insertions(+), 48 deletions(-)
Applied...

 @@ -1225,12 +1224,10 @@ static DBusHandlerResult 
 bus_manager_message_handler(DBusConnection *connection,
  p = bus_path_escape(k);
  if (!p) {
  fclose(f);
 -free(introspection);
  goto oom;
  }
... but you could think about also applying _cleanup_fclose_ here.
This would completely kill the cleanup in error handling blocks,
making things simpler.

  int unit_write_drop_in(Unit *u, UnitSetPropertiesMode mode, const char 
 *name, const char *data) {
 -_cleanup_free_ char *p = NULL, *q = NULL;
 +_cleanup_free_ char *p = NULL;
 +_cleanup_free_ char *q = NULL;
... and I removed those parts which split variable declarations into
separate lines. They were fine as they were.

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

[systemd-devel] fstab-generator: why nofail=true removes Before=$post in .mount

2013-08-07 Thread WANG Chao 
Hi, all

I have a question after looking fstab-generator.c. I hope someone can
help me.

In add_mount(), if nofail=true, Before=$post won't be added to
xxx.mount:

[..]
if (post  !noauto  !nofail  !automount)
fprintf(f,
Before=%s\n,
post);

why doing this?

If nofail=true, that means $post Wants this xxx.mount. And no matter
xxx.mount fails or not, $post will be reached (if post is a target
unit).

I think it's more reasonable to try do xxx.mount before $post. So I'd
like to keep Before=$post in the nofail=true case.

I coud post a patch, but I think it's best to consult to you guys first
in case I'm missing something.


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

Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-08-07 Thread Hoyer, Marko (ADITG/SW2) 
Hi Tony,

best to my experiences, I doubt that suppressing the loading of device units 
will speed up systemd that much. There are other major parts that far more 
significantly delay the startup (cgroups in some cases, loading the unit set at 
startup, executing the generators, and finally loading the binary of systemd 
and the shared libraries ...). You'll probably gain more benefit when starting 
to optimize at these ends ...

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)


Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948

 -Original Message-
 From: systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org
 [mailto:systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org] On
 Behalf Of Tony Seo
 Sent: Thursday, August 08, 2013 3:12 AM
 To: Mantas Mikulėnas
 Cc: systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] How to delete device units presented in systemd-
 analyze plot.
 
 
  I understand what you mean, but I think that I will cut the time for loading
 device unit if I keep those from appearing on my plot.
 
  I want to do a try to temporarily disappear some kinds of device units and
 then I'm supposed to measure boot speed depending a board of mine.(Actually, I
 believe that loading time for device unit affects to boot speed)
 
  What do think that loading time for device units doesn't affect to boot speed
 at machine?
 
  Thanks.
 
 
 
 2013/8/8 Mantas Mikulėnas graw...@gmail.com
 
 
   On Wed, Aug 7, 2013 at 8:03 PM, Tony Seo tonys...@gmail.com wrote:
   
 Hello.
   
Now, I have studied systemd for optimizing systemd on my board.
   
After edited several units, I would like to delete some device
 configuration
units existing on my picture from systemd-analyze(best-dream-
 boy.blogspot)
   
I read the manual pages about systemd.device, I tried to delete
 device units
through editing /etc/fstab and systemctl mask.
   
But I couldn't delete those device units, at least existing units on
 the
picture.
 
 
   You cannot delete these units because they do not exist anywhere
   except in memory – they're only a way to represent device status in
   the format of systemd units. In other words, they do not cause the
   problems you're having; they only make the problems visible in your
   bootchart.
 
   --
   Mantas Mikulėnas graw...@gmail.com
 
 

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