Re: [systemd-devel] Keeping track of usage time

2015-11-03 Thread Tomasz Torcz 
On Tue, Nov 03, 2015 at 07:27:39AM +0100, Umut Tezduyar Lindskog wrote:
> journalctl --list-boots seems great actually but wouldn't work for us.
> We cannot keep lots of logs in our products.
> 
> Ultimately we are trying to answer the question of how long one of our
> product has been in use.
> 
> We will implement it with a .timer/.service which periodically adds
> /proc/uptime to a file and the file gets preserved over reboot.

  Hi,

  there's a daemon which does this: https://github.com/rpodgorny/uptimed

It keeps database in file: 
9932957:1354374472:Linux 3.6.8-1.fc18.x86_64
7635334:1400571727:Linux 3.14.2-200.fc20.x86_64
…

  And has text frontend for interactive use:
% uprecords -M
 #   Uptime | System Boot up
+---
 1   114 days, 23:09:17 | Linux 3.6.8-1.fc18.x86_6  Sat Dec  1 16:07:52 2012
 288 days, 08:55:34 | Linux 3.14.2-200.fc20.x8  Tue May 20 09:42:07 2014
 372 days, 14:59:41 | Linux 3.8.8-203.fc18.x86  Sun Apr 28 18:17:18 2013
 468 days, 03:35:07 | Linux 3.17.1-302.fc21.x8  Mon Oct 20 08:53:07 2014
 566 days, 02:38:32 | Linux 3.12.5-302.fc20.x8  Sun Dec 29 14:38:53 2013
 665 days, 18:50:12 | Linux 3.13.5-202.fc20.x8  Sun Mar  9 20:36:38 2014
 761 days, 15:45:36 | Linux 3.18.1-2.fc22.x86_  Sat Dec 27 15:43:00 2014
 859 days, 12:08:43 | Linux 4.0.0-0.rc2.git0.1  Sun Mar 22 11:13:26 2015
 948 days, 13:06:38 | Linux 3.4.0-1.fc17.x86_6  Thu Jun  7 18:51:12 2012
1044 days, 02:41:34 | Linux 3.11.3-201.fc19.x8  Fri Oct 11 14:34:46 2013
+---
->  2917 days, 18:31:09 | Linux 4.2.3-200.fc22.x86  Fri Oct 16 16:07:22 2015
+---
1up in 0 days, 03:04:28 | atTue Nov  3 12:42:59 2015
t10 in26 days, 08:10:26 | atSun Nov 29 17:48:57 2015
no1 in97 days, 04:38:09 | atMon Feb  8 14:16:40 2016
mst in 7 days, 05:28:52 | twenty-five days  Tue Nov 10 15:07:23 2015
up  1413 days, 06:30:17 | since Sun Jan  1 03:11:26 2012
  down  -11 days, 00:-03:-1 | since Sun Jan  1 03:11:26 2012
   %up  100.785 | since Sun Jan  1 03:11:26 2012


  I see no need to merge it in systemd, really.

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|

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

Re: [systemd-devel] Keeping track of usage time

2015-11-03 Thread Umut Tezduyar Lindskog 
On Tue, Nov 3, 2015 at 1:20 PM, Dimitri John Ledkov
 wrote:
> On 3 November 2015 at 06:27, Umut Tezduyar Lindskog  wrote:
>> journalctl --list-boots seems great actually but wouldn't work for us.
>> We cannot keep lots of logs in our products.
>>
>
> You shouldn't need to keep lots of logs, just a timer unit that would
> query and store/transmit the bootids/deltas (possibly in a round-robin
> fashion)

That is how I am envisioning it. uptimed seems a bit complex for
something so simple.

>
> Regards,
>
> Dimitri.
>
>
>> Ultimately we are trying to answer the question of how long one of our
>> product has been in use.
>>
>> We will implement it with a .timer/.service which periodically adds
>> /proc/uptime to a file and the file gets preserved over reboot.
>>
>> Umut
>>
>> On Mon, Nov 2, 2015 at 7:00 PM, Lennart Poettering
>>  wrote:
>>> On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>>>
 Hi,

 We would like to implement a feature to keep track of accumulated
 values of uptimes in our products. Tracked time will give us the total
 usage time of our product not just since last reboot (/proc/uptime).

 Is upstream interested in having such implementation?
>>>
>>> As Dimitri suggested: wouldn't a journalctl --list-boots invocation
>>> suffice for this?
>>>
>>> Or do you need this per-service? (where the journal should be able to
>>> provide you with the answer too, of course, but with a different line)
>>>
>>> Lennart
>>>
>>> --
>>> Lennart Poettering, Red Hat
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> --
> Regards,
>
> Dimitri.
> 53 sleeps till Christmas, or less
>
> https://clearlinux.org
> Open Source Technology Center
> 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

[systemd-devel] How to set multiple condition to service file

2015-11-03 Thread Jiwon Kim 
Hi systemd-experts,

I'm develop some daemon and it starts on booting time.
But my daemon doesn't has any reason, if there is no 3rd party app.
So, I will set to start condition using "ConditionDirectoryNotEmpty" option.


Bellow is simple test and I checked working successfully.

[Unit]
Description=test1
ConditionDirectoryNotEmpty|=/foo
ConditionDirectoryNotEmpty|=/bar

[Service]
ExecStart=/usr/bin/test1

[Install]
WantedBy=multi-user.target


In this case, starting condition is like this

if (/foo is not empty) or (/bar is not empty) then
start.



But, I hope to set complex condition like this
if (/foo is not empty) or ((/bar is not empty) and (/baz is not empty)) then
start.

I expected bellow setting but it didn't worked.

[Unit]
Description=test2
ConditionDirectoryNotEmpty|=/foo
ConditionDirectoryNotEmpty|=/bar
ConditionDirectoryNotEmpty=/baz

[Service]
ExecStart=/usr/bin/test2

[Install]
WantedBy=multi-user.target


Does any know how to set condition?

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

Re: [systemd-devel] "File exists warning" on first boot

2015-11-03 Thread Umut Tezduyar Lindskog 
This is due to both services (getty@tty1.service and remote-fs.target)
having [Install] section.

I do not know why these services are not shipped without the [Install]
section like the rest of the other systemd services.

Umut

On Tue, Sep 8, 2015 at 10:36 AM, Johan x Lundin  wrote:
> Hello,
>
> On a fresh boot (no /etc/machine-id yet), I'm getting:
> systemd[1]: Failed to populate /etc with preset unit settings, ignoring: File
> exists
>
> The files that systemd is complaining about are installed by systemd
> itself (/etc/systemd/system/getty.target.wants/getty@tty1.service and
> /etc/systemd/system/multi-user.target.wants/remote-fs.target).
>
> Is there any reason not to let these files be populated in /etc on first boot,
> and remove the warning?
>
> Best Regards,
> Johan Lundin
> ___
> 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] Keeping track of usage time

2015-11-03 Thread Dimitri John Ledkov 
On 3 November 2015 at 06:27, Umut Tezduyar Lindskog  wrote:
> journalctl --list-boots seems great actually but wouldn't work for us.
> We cannot keep lots of logs in our products.
>

You shouldn't need to keep lots of logs, just a timer unit that would
query and store/transmit the bootids/deltas (possibly in a round-robin
fashion)

Regards,

Dimitri.


> Ultimately we are trying to answer the question of how long one of our
> product has been in use.
>
> We will implement it with a .timer/.service which periodically adds
> /proc/uptime to a file and the file gets preserved over reboot.
>
> Umut
>
> On Mon, Nov 2, 2015 at 7:00 PM, Lennart Poettering
>  wrote:
>> On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>>
>>> Hi,
>>>
>>> We would like to implement a feature to keep track of accumulated
>>> values of uptimes in our products. Tracked time will give us the total
>>> usage time of our product not just since last reboot (/proc/uptime).
>>>
>>> Is upstream interested in having such implementation?
>>
>> As Dimitri suggested: wouldn't a journalctl --list-boots invocation
>> suffice for this?
>>
>> Or do you need this per-service? (where the journal should be able to
>> provide you with the answer too, of course, but with a different line)
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.
53 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
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-nspawn and process spawning using nsenter issue

2015-11-03 Thread Lennart Poettering 
On Mon, 02.11.15 20:35, Aliaksei Sheshka (sheshka...@gmail.com) wrote:

> >
> > Note that all units you join need to have PrivateNetwork=yes set if
> > they shall live in the same namespace. Did both your units have this set?
> 
> I have my unit c7-test like that:
> 
> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
> --link-journal=try-guest --network-macvlan=eth0 --settings=override
> --machine=c7-test
> 
> --networ-macvlan assumes  PrivateNetwork as I understand.
> If I add additional  "PrivateNetwork=yes" to that nspawn unit, it
> won't work, since, obviously, eth0 is no longer available.

Well, not only that, but nspawn opens a new network namespace for the
container as soon as you use any of the --network-xyz or
--private-network switches, but nspawn itself will stay outside...

> In short my goal to have macvlan enabled systemd-nspawn container
> running. Once it's up, I would like to run a daemon withing that
> container ip namespace using binary located on the host system.
> Current 'nsenter' solution looks not that elegant.  Perhaps there is a
> better way to achieve that.

I don't see how, sorry...

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 2/2] detect-virt: dmi: look for KVM

2015-11-03 Thread systemd github import bot 
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting nmb.service from within a program

2015-11-03 Thread Paul D. DeRocco 
> From: Mantas Mikulenas [mailto:graw...@gmail.com] 
> 
> Pretty sure it's documented:
> 
> http://www.freedesktop.org/wiki/Software/systemd/dbus/
> 
> http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
> 
> and so on.

Thanks. D-Bus looks like the correct way to do it.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

[systemd-devel] Restarting nmb.service from within a program

2015-11-03 Thread Paul D. DeRocco 
I have a Yocto embedded system running a simple Samba 4 server, using
systemd. I'm relying on the system hostname being the default netbios
name, and I need to be able to change the hostname, and therefore the
netbios name, from within my main application. I write the new hostname to
/etc/hostname, and also call sethostname(), but in order for the change to
take effect, the nmbd daemon (that is, nmb.service) needs to be restarted.

Since systemd is managing this service, it seems I should be accomplishing
this by telling systemd to restart the service. Is there a documented way
to do this from within a program? There must be some way, since systemctl
does it.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

[systemd-devel] [PATCH 2/2] detect-virt: dmi: look for KVM

2015-11-03 Thread Andrew Jones 
Some guests (ARM, AArch64, x86-RHEL) have 'KVM' in the product name.
Look for that first in order to more precisely report "kvm" when
detecting a QEMU/KVM guest. Without this patch we report "qemu",
even if KVM acceleration is in use on ARM/AArch64 guests.
---
 src/basic/virt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/basic/virt.c b/src/basic/virt.c
index b0e33dc5f4d24..254dc7dba4dd9 100644
--- a/src/basic/virt.c
+++ b/src/basic/virt.c
@@ -147,6 +147,7 @@ static int detect_vm_dmi(void) {
 #if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__)
 
 static const char *const dmi_vendors[] = {
+"/sys/class/dmi/id/product_name", /* Test this before 
sys_vendor to detect KVM over QEMU */
 "/sys/class/dmi/id/sys_vendor",
 "/sys/class/dmi/id/board_vendor",
 "/sys/class/dmi/id/bios_vendor"
@@ -156,6 +157,7 @@ static int detect_vm_dmi(void) {
 const char *vendor;
 int id;
 } dmi_vendor_table[] = {
+{ "KVM",   VIRTUALIZATION_KVM   },
 { "QEMU",  VIRTUALIZATION_QEMU  },
 /* 
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=1009458
 */
 { "VMware",VIRTUALIZATION_VMWARE},
-- 
2.4.3

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

Re: [systemd-devel] Restarting nmb.service from within a program

2015-11-03 Thread Mantas Mikulėnas 
On Tue, Nov 3, 2015 at 9:44 PM, Paul D. DeRocco 
wrote:

> I have a Yocto embedded system running a simple Samba 4 server, using
> systemd. I'm relying on the system hostname being the default netbios
> name, and I need to be able to change the hostname, and therefore the
> netbios name, from within my main application. I write the new hostname to
> /etc/hostname, and also call sethostname(), but in order for the change to
> take effect, the nmbd daemon (that is, nmb.service) needs to be restarted.
>
> Since systemd is managing this service, it seems I should be accomplishing
> this by telling systemd to restart the service. Is there a documented way
> to do this from within a program? There must be some way, since systemctl
> does it.
>

Pretty sure it's documented:

http://www.freedesktop.org/wiki/Software/systemd/dbus/

http://www.freedesktop.org/wiki/Software/systemd/hostnamed/

and so on.

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

[systemd-devel] [PATCH 2/2] detect-virt: dmi: fix mem leak

2015-11-03 Thread Andrew Jones 
The variable 's' is still in scope until we exit the function. We
can't call read_one_line_file on it multiple times without calling
free in between.
---
 src/basic/virt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/basic/virt.c b/src/basic/virt.c
index 1e10fc755f201..f88bd04bd72ed 100644
--- a/src/basic/virt.c
+++ b/src/basic/virt.c
@@ -176,9 +176,10 @@ static int detect_vm_dmi(void) {
 
 r = read_one_line_file(dmi_vendors[i], );
 if (r < 0) {
-if (r == -ENOENT)
+if (r == -ENOENT) {
+free(s);
 continue;
-
+}
 return r;
 }
 
-- 
2.4.3

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

[systemd-devel] [PATCH 0/2] detect-virt: fixes

2015-11-03 Thread Andrew Jones 
These fixes are untested, as I don't have a good test environment for
systemd. I noticed the issues in the code while preparing a couple
patches (which are coming shortly).

Andrew Jones (2):
  detect-virt: detect in best-heuristic order
  detect-virt: dmi: fix mem leak

 src/basic/virt.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

-- 
2.4.3

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

[systemd-devel] [PATCH 1/2] detect-virt: detect in best-heuristic order

2015-11-03 Thread Andrew Jones 
afaict, this will fix a regression caused by commit 75f86906c5.
Where we used to report "kvm" before that patch, without this patch,
we would only report "qemu". The reason is because cpuid detection
must come before dmi detection. Also, both can safely come before
other xen heuristics.
---
 src/basic/virt.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/basic/virt.c b/src/basic/virt.c
index fb181e5b55ee5..1e10fc755f201 100644
--- a/src/basic/virt.c
+++ b/src/basic/virt.c
@@ -267,12 +267,7 @@ int detect_vm(void) {
 if (cached_found >= 0)
 return cached_found;
 
-/* Try xen capabilities file first, if not found try
- * high-level hypervisor sysfs file:
- *
- * https://bugs.freedesktop.org/show_bug.cgi?id=77271 */
-
-r = detect_vm_xen();
+r = detect_vm_cpuid();
 if (r < 0)
 return r;
 if (r != VIRTUALIZATION_NONE)
@@ -284,7 +279,14 @@ int detect_vm(void) {
 if (r != VIRTUALIZATION_NONE)
 goto finish;
 
-r = detect_vm_cpuid();
+/* x86 xen will most likely be detected by cpuid. If not (most likely
+ * because we're not an x86 guest), then we should try the xen 
capabilities
+ * file next. If that's not found, then we check for the high-level
+ * hypervisor sysfs file:
+ *
+ * https://bugs.freedesktop.org/show_bug.cgi?id=77271 */
+
+r = detect_vm_xen();
 if (r < 0)
 return r;
 if (r != VIRTUALIZATION_NONE)
-- 
2.4.3

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

Re: [systemd-devel] [PATCH 2/2] detect-virt: dmi: fix mem leak

2015-11-03 Thread systemd github import bot 
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting nmb.service from within a program

2015-11-03 Thread Reindl Harald 



Am 03.11.2015 um 20:44 schrieb Paul D. DeRocco:

I have a Yocto embedded system running a simple Samba 4 server, using
systemd. I'm relying on the system hostname being the default netbios
name, and I need to be able to change the hostname, and therefore the
netbios name, from within my main application. I write the new hostname to
/etc/hostname, and also call sethostname(), but in order for the change to
take effect, the nmbd daemon (that is, nmb.service) needs to be restarted.

Since systemd is managing this service, it seems I should be accomplishing
this by telling systemd to restart the service. Is there a documented way
to do this from within a program? There must be some way, since systemctl
does it


and why don't you just call systemctl?

that's even from php scripts with exec() or passthru() a no brainer



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 1/2] arm/aarch64: detect-virt: check dmi

2015-11-03 Thread Andrew Jones 
---
 src/basic/virt.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/basic/virt.c b/src/basic/virt.c
index fb181e5b55ee5..b0e33dc5f4d24 100644
--- a/src/basic/virt.c
+++ b/src/basic/virt.c
@@ -34,7 +34,7 @@
 
 static int detect_vm_cpuid(void) {
 
-/* Both CPUID and DMI are x86 specific interfaces... */
+/* CPUID is an x86 specific interface. */
 #if defined(__i386__) || defined(__x86_64__)
 
 static const struct {
@@ -144,9 +144,7 @@ static int detect_vm_device_tree(void) {
 }
 
 static int detect_vm_dmi(void) {
-
-/* Both CPUID and DMI are x86 specific interfaces... */
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__)
 
 static const char *const dmi_vendors[] = {
 "/sys/class/dmi/id/sys_vendor",
-- 
2.4.3

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

[systemd-devel] [PATCH 0/2] arm/aarch64: detect-virt: check dmi

2015-11-03 Thread Andrew Jones 
ARM/AArch64 guests now have SMBIOS tables populated (when boot
with a late enough QEMU and a late enough AAVMF is used as the
bootloader). Furthermore, when booting ARM/AArch64 guests with
ACPI, the DT detection obviously no longer works, so we need
dmi detection. Finally, we can now even determine KVM vs. QEMU
as the SMBIOS contains 'KVM' in the product name, when using kvm.

The first patch in this series enables dmi detection on
arm/aarch64. The second patch looks for KVM in the product name.
I've only tested a backported version of these patches on an
AArch64 guest (which worked). Of course it would be nice to get
regression testing on all guest types that depend on dmi done.

Andrew Jones (2):
  arm/aarch64: detect-virt: check dmi
  detect-virt: dmi: look for KVM

 src/basic/virt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.4.3

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

Re: [systemd-devel] [PATCH 1/2] arm/aarch64: detect-virt: check dmi

2015-11-03 Thread Wei Huang 


On 11/03/2015 03:19 PM, Andrew Jones wrote:
> ---
>  src/basic/virt.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/src/basic/virt.c b/src/basic/virt.c
> index fb181e5b55ee5..b0e33dc5f4d24 100644
> --- a/src/basic/virt.c
> +++ b/src/basic/virt.c
> @@ -34,7 +34,7 @@
>  
>  static int detect_vm_cpuid(void) {
>  
> -/* Both CPUID and DMI are x86 specific interfaces... */
> +/* CPUID is an x86 specific interface. */
>  #if defined(__i386__) || defined(__x86_64__)
>  
>  static const struct {
> @@ -144,9 +144,7 @@ static int detect_vm_device_tree(void) {
>  }
>  
>  static int detect_vm_dmi(void) {
> -
> -/* Both CPUID and DMI are x86 specific interfaces... */
> -#if defined(__i386__) || defined(__x86_64__)
> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
> defined(__aarch64__)
>  
>  static const char *const dmi_vendors[] = {
>  "/sys/class/dmi/id/sys_vendor",
> 

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

Re: [systemd-devel] [PATCH 0/2] arm/aarch64: detect-virt: check dmi

2015-11-03 Thread Wei Huang 


On 11/03/2015 03:19 PM, Andrew Jones wrote:
> ARM/AArch64 guests now have SMBIOS tables populated (when boot
> with a late enough QEMU and a late enough AAVMF is used as the
> bootloader). Furthermore, when booting ARM/AArch64 guests with
> ACPI, the DT detection obviously no longer works, so we need
^^
I think DT detection still works, right? But just because we have other
testing cases prior to device_tree, dt detection won't be triggered.

> dmi detection. Finally, we can now even determine KVM vs. QEMU
> as the SMBIOS contains 'KVM' in the product name, when using kvm.
> 
> The first patch in this series enables dmi detection on
> arm/aarch64. The second patch looks for KVM in the product name.
> I've only tested a backported version of these patches on an
> AArch64 guest (which worked). Of course it would be nice to get
> regression testing on all guest types that depend on dmi done.
> 
> Andrew Jones (2):
>   arm/aarch64: detect-virt: check dmi
>   detect-virt: dmi: look for KVM
> 
>  src/basic/virt.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] detect-virt: dmi: look for KVM

2015-11-03 Thread Wei Huang 


On 11/03/2015 03:19 PM, Andrew Jones wrote:
> Some guests (ARM, AArch64, x86-RHEL) have 'KVM' in the product name.

See bab27ea2 of qemu tree...

> Look for that first in order to more precisely report "kvm" when
> detecting a QEMU/KVM guest. Without this patch we report "qemu",
> even if KVM acceleration is in use on ARM/AArch64 guests.
> ---
>  src/basic/virt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/basic/virt.c b/src/basic/virt.c
> index b0e33dc5f4d24..254dc7dba4dd9 100644
> --- a/src/basic/virt.c
> +++ b/src/basic/virt.c
> @@ -147,6 +147,7 @@ static int detect_vm_dmi(void) {
>  #if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
> defined(__aarch64__)
>  
>  static const char *const dmi_vendors[] = {
> +"/sys/class/dmi/id/product_name", /* Test this before 
> sys_vendor to detect KVM over QEMU */
>  "/sys/class/dmi/id/sys_vendor",
>  "/sys/class/dmi/id/board_vendor",
>  "/sys/class/dmi/id/bios_vendor"
> @@ -156,6 +157,7 @@ static int detect_vm_dmi(void) {
>  const char *vendor;
>  int id;
>  } dmi_vendor_table[] = {
> +{ "KVM",   VIRTUALIZATION_KVM   },
>  { "QEMU",  VIRTUALIZATION_QEMU  },
>  /* 
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US=displayKC=1009458
>  */
>  { "VMware",VIRTUALIZATION_VMWARE},
> 

This should work for any QEMU target that supports smbios after
bab27ea2 commit. So I am OK with it.

reviewed-by: Wei Huang 

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