Re: [systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop

2017-02-24 Thread Jani Nikula
On Fri, 24 Feb 2017, Jani Nikula  wrote:
> While both the DMI and ACPI data are regarded as unreliable in hostnamed
> source, consumers of the chassis type use it to make rather drastic
> policy decisions.

BTW, since the implementation seems to think the data is unreliable,
perhaps it would be prudent to say so in hostnamectl documentation, so
the consumers of the data might be more thoughtful about what to use it
for?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop

2017-02-24 Thread Jani Nikula
Currently the DMI convertible chassis type is disregarded by
hostnamed. The fallback ACPI data might indicate either laptop or
tablet. For example, Lenovo Yoga 910 is convertible per DMI data, but
tablet per ACPI data, and therefore receives tablet chassis type. Regard
convertibles as laptops to avoid the risk of them being labeled as
tablets.

While both the DMI and ACPI data are regarded as unreliable in hostnamed
source, consumers of the chassis type use it to make rather drastic
policy decisions. For example, Gnome forcefully autosuspends all tablet
type machines when the screen is blanked, regardless of other
autosuspend options. Arguably that's a bug in Gnome (and it's being
argued at [1]), but some of the issues there, and elsewhere, can be
mitigated by considering convertibles as laptops here.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=764723

---

Alas, I failed to build systemd, so I'm afraid you'll have to consider
this a bug report more than a real submission. :(
---
 src/hostname/hostnamed.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 4657cf8c77b2..bcc3d457403b 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -187,6 +187,7 @@ static const char* fallback_chassis(void) {
 case 0x9: /* Laptop */
 case 0xA: /* Notebook */
 case 0xE: /* Sub Notebook */
+case 0x1F: /* Convertible */
 return "laptop";
 
 case 0xB: /* Hand Held */
-- 
2.1.4

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


Re: [systemd-devel] [PATCH] hostnamed: regard convertible chassis type as laptop

2017-02-24 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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] udev virtio by-path naming

2017-02-24 Thread Viktor Mihajlovski
On 20.02.2017 17:00, Cornelia Huck wrote:
> On Mon, 20 Feb 2017 15:34:49 +0100
> Viktor Mihajlovski  wrote:
> 
>> Hi,
>>
>> with systemd > v229 all virtio block devices will receive persistent
>> device names in the format /dev/disk-by/virtio-pci-, the
>> last component being the udev built-in path_id.
>>
>> This naming introduces some issues.
>>
>> First and obvious, there are virtio implementations not based
>> on PCI, like virtio-ccw (currently only on s390) and virtio-mmio
>> (for which I can't speak). This results in persistent names like
>> /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id.
>> One seemingly obvious remedy would be to make the path_id return
>> virtio-ccw- or more generally virtio--,
>> both easily done with small patches to systemd-udev.
>>
>> But then, I find this naming scheme somewhat weird.
>> A virtio disk shows up as a regular PCI function on the PCI
>> bus side by side with other (non-virtio) devices. The naming otoh
>> suggests that virtio-pci is a subsystem of its own, which is simply
>> incorrect from a by-path perspective.
> 
> From the ccw perspective, this is quite similar: The virtio proxy
> device shows up on the ccw bus, just like e.g. a dasd device shows up
> on the ccw bus.
> 
>>
>> Using just the plain PCI path id is actually sufficient to identify
>> a virtio disk by its path. This would be in line with virtio
>> network interface path names which use the plain PCI naming.
> 
> Same for ccw: The id on the ccw bus (devno) is already unique and
> persistent.
> 
>>
>> One could argue about back-level compatibility, but virtio by-path
>> naming has changed multiple times. We have seen virtio-pci-virtio
>> (not predictable), pci- and virtio-pci- already. It
>> might be a good time now to settle on a common approach for all
>> virtio types.
>>
>> For the reasons above, I'd vote for -, which
>> would work for PCI and CCW, not sure about ARM MMIO though.
>> Opinions?
> 
> I'm not sure whether there is any reason to make virtio special,
> although this depends upon what virtio-mmio looks like in the Linux
> device model (any arm folks here?)
> 
> In the end, I'd be happy with any naming scheme that does not include
> 'pci' for non-pci devices.
> 
Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407
that introduced this behavior: can you comment on the reasoning for
prepending virtio- to the bus, i.e. why would pci- not
sufficiently identify the device?

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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