Re: [systemd-devel] About stable network interface names

[Greg KH]

On Sat, Jun 10, 2017 at 09:08:17AM +0300, Andrei Borzenkov wrote:
> 09.06.2017 23:42, Martin Wilck пишет:
> > On Tue, 2017-06-06 at 21:40 +0300, Andrei Borzenkov wrote:
> >>
> >> Can device and function really change? My understanding is that
> >> device
> >> part is determined by bus physical wiring and function by PCI card
> >> design; this leaves bus as volatile run-time enumeration value.
> > 
> > For PCIe, that's only true for the "function" part.
> > https://superuser.com/questions/1060808/how-is-the-device-determined-in
> > -pci-enumeration-bus-device-function
> > 
> 
> I do not see anything there that would imply device designation is
> random. You have PCIe switch port instead of IDSEL wiring but port is
> most likely hardwired and does not change. Actually this article says
> the same
> 
> --><--
> Since each device has its own independent set of wires, the device IDs
> are essentially all hard-coded
> --><--

"essentially" does not mean "will never change".  Some BIOSes will
renumber them, some will not, as it's not a PCI requirement it can, and
will, happen.

Yes, for lots of people this will be fine and nothing will ever change,
but you can not guarantee it will never happen for all types of
machines, sorry.

That's just the nature of dynamic busses :)

good luck!

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

Re: [systemd-devel] About stable network interface names

[Andrei Borzenkov]

09.06.2017 23:42, Martin Wilck пишет:
> On Tue, 2017-06-06 at 21:40 +0300, Andrei Borzenkov wrote:
>>
>> Can device and function really change? My understanding is that
>> device
>> part is determined by bus physical wiring and function by PCI card
>> design; this leaves bus as volatile run-time enumeration value.
> 
> For PCIe, that's only true for the "function" part.
> https://superuser.com/questions/1060808/how-is-the-device-determined-in
> -pci-enumeration-bus-device-function
> 

I do not see anything there that would imply device designation is
random. You have PCIe switch port instead of IDSEL wiring but port is
most likely hardwired and does not change. Actually this article says
the same

--><--
Since each device has its own independent set of wires, the device IDs
are essentially all hard-coded
--><--


> The systemd docs are a bit misleading for PCIe, as they talk about
> "physical/geographical location" for the common enp$Xs$Yf$Z scheme,
> which is actually just the BDF. The interface on my laptop is called
> enp0s31f6 although the laptop doesn't have "slot 31". (1)
> 

The reason for this scheme is to generate unique names during boot. All
this buzz about "predictability" etc is just usual marketing stuff to
better sell it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

On 06/08/2017 11:03 PM, Ian Pilcher wrote:

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.


Replying to myself for posterity ...

As so often seems to be the case, my difficulties were due to that
recurring issue, "You're doing it wrong."

TL;DR - Setting different MTUs on different ports of an OVS bridge
doesn't work as expected, so using separate tagged ports on the host OS
isn't the way to go.

Instead, create VLAN netdevs on top of the trunked OVS port (treating
it as if it were a physical interface or bond).  For example:

98-ovs0.link:

[Match]
OriginalName=ovs0

[Link]
MTUBytes=8996

ovs0.network:

[Match]
Name=ovs0

[Network]
VLAN=ovs0.248
VLAN=ovs0.250

ovs0.248.netdev:

[NetDev]
Name=ovs0.248
Kind=vlan

[VLAN]
Id=248

ovs0.250.netdev:

[NetDev] 

Name=ovs0.250 

Kind=vlan 

MTUBytes=1500 




[VLAN] 


Id=250

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

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

Re: [systemd-devel] About stable network interface names

[Martin Wilck]

On Tue, 2017-06-06 at 21:40 +0300, Andrei Borzenkov wrote:
> 
> Can device and function really change? My understanding is that
> device
> part is determined by bus physical wiring and function by PCI card
> design; this leaves bus as volatile run-time enumeration value.

For PCIe, that's only true for the "function" part.
https://superuser.com/questions/1060808/how-is-the-device-determined-in
-pci-enumeration-bus-device-function

The systemd docs are a bit misleading for PCIe, as they talk about
"physical/geographical location" for the common enp$Xs$Yf$Z scheme,
which is actually just the BDF. The interface on my laptop is called
enp0s31f6 although the laptop doesn't have "slot 31". (1)

Martin

(1) Well, that's actually because the manufacturer saved the money to
implement the DMI BIOS correctly: there is even a DMI type 41 entry for
onboard LAN, but the PCI device number (sic!) is wrong.

-- 
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

Re: [systemd-devel] [RFC] AddMatch on a private/direct bus

[Simon McVittie]

On Fri, 09 Jun 2017 at 15:20:49 +0200, Łukasz Stelmach wrote:
> We are developing a daemon that is monitoring a system. One of its
> sources of information is systemd. To avoid dependency on dbus-daemon
> (which may fail and cripple our daemon) the daemon connects to
> /run/systemd/private to listen to signals emitted by systemd. However,
> we don't need all signals, only a few. Thus we are going to create code
> which will filter and dispatch signals.

> We think the best place for such code is not our daemon but rather
> sd-bus. Our question is: would you accept the patch adding a signal
> filter/dispatcher for direct DBus connections? Do you have any
> recommendation for such functionality

Please don't call it a private *bus* unless it implements the full API of
the dbus-daemon, or at least something the same "shape" as that. D-Bus
terminology makes a distinction between connections to a server (one or
more clients connect to one server, which processes messages itself) and
to a bus (clients connect to a server/broker/hub in the middle of a star
topology, the "message bus", and the message bus in the middle forwards
messages between clients and implements the standard org.freedesktop.DBus
APIs, including signal subscriptions and name ownership). As far as I'm
aware, /run/systemd/private is not a bus in those terms: clients that
connect to it can talk directly to systemd, but cannot talk to each
other. A private or direct D-Bus *connection* seems a better term.

The device nodes in kdbus were effectively buses, although using
ioctls instead of the org.freedesktop.DBus interface - they delivered
messages between clients, mediated name ownership and so on. I don't
think kdbus had an equivalent of private/direct D-Bus connections.

Receiving signals on a private/direct connection with the equivalent
of g_dbus_connection_signal_subscribe() seems like a reasonable thing
for sd-bus to have, if its maintainers want that. I think GDBus'
g_dbus_connection_signal_subscribe() works fine on private/direct
connections if you pass in G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE.

However, are you also proposing writing a reimplementation of
the dbus-daemon's signal subscription matching as configured
by AddMatch(), and running it on the service side, so
in this case in systemd? Or are you confusing client-side
subscription (e.g.  g_dbus_connection_signal_subscribe() with
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE) with bus-side filtering (adding
match rules)?

If you are considering reimplementing signal subscription, I would
recommend first benchmarking the most naive possible implementation (a
connection is either subscribed to all signals from systemd or no signals,
and ignores the unwanted ones client-side). I suspect you might find that
doing the filtering client-side is not a performance problem in practice;
depending how optimal the server-side filtering implementation is,
server-side filtering might even end up more "expensive" than just
delivering everything and requiring clients to cope, because D-Bus
signal subscription is a lot more general-purpose than what would
be useful to you in this situation in practice.

If you do find that you need server-side filtering, I think I'd prefer it
if you used a non-standard interface name for your signal subscription
mechanism (so org.freedesktop.systemd1.Manager.AddMatch() or something
rather than org.freedesktop.DBus.AddMatch()), although clearly you're
welcome to use the same syntax for subscriptions that AddMatch uses.
I would prefer not to cloud the distinction between connections and
buses by implementing subsets of the org.freedesktop.DBus interface on
non-buses: each connection should either be direct, or a full bus.

A much simpler subscription language (some sort of middle ground between
the simplicity of o.fd.systemd1.Manager.Subscribe() and the complexity
of o.fd.DBus.AddMatch()) might be another option.

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

[systemd-devel] [RFC] AddMatch on a private/direct bus

[Łukasz Stelmach]

Hi.

We are developing a daemon that is monitoring a system. One of its
sources of information is systemd. To avoid dependency on dbus-daemon
(which may fail and cripple our daemon) the daemon connects to
/run/systemd/private to listen to signals emitted by systemd. However,
we don't need all signals, only a few. Thus we are going to create code
which will filter and dispatch signals.

We think the best place for such code is not our daemon but rather
sd-bus. Our question is: would you accept the patch adding a signal
filter/dispatcher for direct DBus connections? Do you have any
recommendation for such functionality

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics


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

[systemd-devel] udev hwdb add unknown button

[Floris]

I have an older ASUS R2E UMPC[1], which has a couple of media buttons. One  
button isn't recognized and print:


asus_laptop: Unknown key 9a pressed

I tried to add this button with an udev hwdb rule in  
/etc/udev/hwdb.d/99-keyboard.hwdb


evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS:pn*pvr*
 KEYBOARD_KEY_95=keyboard   <-- This one is added for testing 
purposes
 KEYBOARD_KEY_9a=screen


after an udevadm update and trigger, udevadm info /dev/input/event5  
reports the buttons:

...
E: ID_PATH_TAG=platform-asus_laptop
E: KEYBOARD_KEY_6b=f21  <-- This one is a default udev 
hwdb rule
E: KEYBOARD_KEY_95=keybaord
E: KEYBOARD_KEY_9a=screen
E: LIBINPUT_DEVICE_GROUP=19/0/0/0:asus_laptop
...

So far everything works as expected, but evtest doesn't show the remap of  
the 9a key

...
type 4 (EV_MSC), code 4 (MSC_SCAN), value 95
type 1 (EV_KEY), code 374 (KEY_KEYBOARD), value 1		<-- This one is  
modified as expected

...
type 4 (EV_MSC), code 4 (MSC_SCAN), value 9a
type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1		<-- Why isn't this one  
modified?

...

Only after adding {KE_KEY, 0x9a, { KEY_SCREEN } }, to asus-laptop.c line  
355 [2] and rebuild the kernel module, I am able to remap and use the  
media button on the laptop.


Is this a flaw in the kernel module or in udev?

Floris


[1] https://www.asus.com/Laptops/R2E/
[2]  
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/platform/x86/asus-laptop.c?h=v4.9.30

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