[systemd-devel] Utility for persistent alternative driver binding

[Panu Matilainen]

Hi all,

To follow-up on this thread from September-October:
http://lists.freedesktop.org/archives/systemd-devel/2015-September/034427.html
http://lists.freedesktop.org/archives/systemd-devel/2015-October/034551.html

The driverctl utility has matured a bit from the earliest tyre-kicking 
version seen there and now lives at laiskiainen.org/git/?p=driverctl.git


Since it has everything to do with udev this seems like a reasonable 
forum to advertise it a bit. Quoting from the README a bit:



driverctl is a tool for manipulating and inspecting the system
device driver choices.

Devices are normally assigned to their sole designated kernel driver
by default. However in some situations it may be desireable to
override that default, for example to try an older driver to
work around a regression in a driver or to try an experimental alternative
driver. Another common use-case is pass-through drivers and driver
stubs to allow userspace to drive the device, such as in case of
virtualization.

driverctl integrates with udev to support overriding
driver selection for both cold- and hotplugged devices from the
moment of discovery, but can also change already assigned drivers,
assuming they are not in use by the system. The driver overrides
created by driverctl are persistent across system reboots
by default.

>

Usage
-

Find devices currently driven by ixgbe driver:

# driverctl -v list-devices | grep ixgbe
:01:00.0 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
:01:00.1 ixgbe (Ethernet 10G 4P X520/I350 rNDC)

Change them to use the vfio-pci driver:
# driverctl set-override :01:00.0 vfio-pci
# driverctl set-override :01:00.1 vfio-pci

Find devices with driver overrides:
# driverctl -v list-devices|grep \\*
:01:00.0 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
:01:00.1 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)

Remove the override from slot :01:00.1:
# driverctl unset-override :01:00.1


The other reason for posting here is: is there interest in having such a 
utility would find home in udev/systemd?


Note that I'm not trying to sell you the current shell-spaghetti 
implementation, its mostly just a demonstration of the interface which 
is modeled after the various *ctl utilities in systemd. The idea is to 
rewrite it properly in C anyway, but at this point it'd be useful to 
know from style/infrastructure/etc perspective whether there's interest 
in having such a thing included in systemd afterall.


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

Re: [systemd-devel] Utility for persistent alternative driver binding

[poma]

On 04.12.2015 10:40, Panu Matilainen wrote:
> Hi all,
> 
> To follow-up on this thread from September-October:
> http://lists.freedesktop.org/archives/systemd-devel/2015-September/034427.html
> http://lists.freedesktop.org/archives/systemd-devel/2015-October/034551.html
> 
> The driverctl utility has matured a bit from the earliest tyre-kicking 
> version seen there and now lives at laiskiainen.org/git/?p=driverctl.git
> 
> Since it has everything to do with udev this seems like a reasonable 
> forum to advertise it a bit. Quoting from the README a bit:
> 
>> driverctl is a tool for manipulating and inspecting the system
>> device driver choices.
>>
>> Devices are normally assigned to their sole designated kernel driver
>> by default. However in some situations it may be desireable to
>> override that default, for example to try an older driver to
>> work around a regression in a driver or to try an experimental alternative
>> driver. Another common use-case is pass-through drivers and driver
>> stubs to allow userspace to drive the device, such as in case of
>> virtualization.
>>
>> driverctl integrates with udev to support overriding
>> driver selection for both cold- and hotplugged devices from the
>> moment of discovery, but can also change already assigned drivers,
>> assuming they are not in use by the system. The driver overrides
>> created by driverctl are persistent across system reboots
>> by default.
>  >
>> Usage
>> -
>>
>> Find devices currently driven by ixgbe driver:
>>
>> # driverctl -v list-devices | grep ixgbe
>> :01:00.0 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
>> :01:00.1 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
>>
>> Change them to use the vfio-pci driver:
>> # driverctl set-override :01:00.0 vfio-pci
>> # driverctl set-override :01:00.1 vfio-pci
>>
>> Find devices with driver overrides:
>> # driverctl -v list-devices|grep \\*
>> :01:00.0 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
>> :01:00.1 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
>>
>> Remove the override from slot :01:00.1:
>> # driverctl unset-override :01:00.1
> 
> The other reason for posting here is: is there interest in having such a 
> utility would find home in udev/systemd?
> 
> Note that I'm not trying to sell you the current shell-spaghetti 
> implementation, its mostly just a demonstration of the interface which 
> is modeled after the various *ctl utilities in systemd. The idea is to 
> rewrite it properly in C anyway, but at this point it'd be useful to 
> know from style/infrastructure/etc perspective whether there's interest 
> in having such a thing included in systemd afterall.
> 

version 0.2?
driverctl + udevadm + add/edit/test/del udev-rules files (rather than working 
with files directly) = udevctl™


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

Re: [systemd-devel] Utility for persistent alternative driver binding

[poma]

On 04.12.2015 15:27, poma wrote:
> On 04.12.2015 10:40, Panu Matilainen wrote:
>> Hi all,
>>
>> To follow-up on this thread from September-October:
>> http://lists.freedesktop.org/archives/systemd-devel/2015-September/034427.html
>> http://lists.freedesktop.org/archives/systemd-devel/2015-October/034551.html
>>
>> The driverctl utility has matured a bit from the earliest tyre-kicking 
>> version seen there and now lives at laiskiainen.org/git/?p=driverctl.git
>>
>> Since it has everything to do with udev this seems like a reasonable 
>> forum to advertise it a bit. Quoting from the README a bit:
>>
>>> driverctl is a tool for manipulating and inspecting the system
>>> device driver choices.
>>>
>>> Devices are normally assigned to their sole designated kernel driver
>>> by default. However in some situations it may be desireable to
>>> override that default, for example to try an older driver to
>>> work around a regression in a driver or to try an experimental alternative
>>> driver. Another common use-case is pass-through drivers and driver
>>> stubs to allow userspace to drive the device, such as in case of
>>> virtualization.
>>>
>>> driverctl integrates with udev to support overriding
>>> driver selection for both cold- and hotplugged devices from the
>>> moment of discovery, but can also change already assigned drivers,
>>> assuming they are not in use by the system. The driver overrides
>>> created by driverctl are persistent across system reboots
>>> by default.
>>  >
>>> Usage
>>> -
>>>
>>> Find devices currently driven by ixgbe driver:
>>>
>>> # driverctl -v list-devices | grep ixgbe
>>> :01:00.0 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
>>> :01:00.1 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
>>>
>>> Change them to use the vfio-pci driver:
>>> # driverctl set-override :01:00.0 vfio-pci
>>> # driverctl set-override :01:00.1 vfio-pci
>>>
>>> Find devices with driver overrides:
>>> # driverctl -v list-devices|grep \\*
>>> :01:00.0 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
>>> :01:00.1 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
>>>
>>> Remove the override from slot :01:00.1:
>>> # driverctl unset-override :01:00.1
>>
>> The other reason for posting here is: is there interest in having such a 
>> utility would find home in udev/systemd?
>>
>> Note that I'm not trying to sell you the current shell-spaghetti 
>> implementation, its mostly just a demonstration of the interface which 
>> is modeled after the various *ctl utilities in systemd. The idea is to 
>> rewrite it properly in C anyway, but at this point it'd be useful to 
>> know from style/infrastructure/etc perspective whether there's interest 
>> in having such a thing included in systemd afterall.
>>
> 
> version 0.2?
> driverctl + udevadm + add/edit/test/del udev-rules files (rather than working 
> with files directly) = udevctl™
> 
> 

e.g.
# udevctl --driver list-devices | set-override | unset-override ...
# udevctl --admin control | hwdb | monitor ...
# udevctl --rule add | edit | test | del ...
...



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

[systemd-devel] systemd nspawn container - download speed slow

[arnaud gaboury]

Here is my setup:

Arch host
Fedora 23 nspawn container
Network:
From host:
---

 % ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp7s0:  mtu 1500 qdisc pfifo_fast
master br0 state UP group default qlen 1000
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link
   valid_lft forever preferred_lft forever
3: br0:  mtu 1500 qdisc noqueue state
UP group default
link/ether b6:0c:00:22:f1:4a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 fe80::b40c:ff:fe22:f14a/64 scope link
   valid_lft forever preferred_lft forever
4: vb-poppy@if2:  mtu 1500 qdisc
pfifo_fast master br0 state UP group default qlen 1000
link/ether 0e:9a:d7:18:a3:59 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::c9a:d7ff:fe18:a359/64 scope link
   valid_lft forever preferred_lft forever
--

I remark that download speed is much slower in container. Is it
normal? If not, how shall I deal with it?

Thank you for hints.


-- 

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

[systemd-devel] Additional error details when resource limits are exceeded

[Peter Hoeg]

Hi,

I'm using systemd 228-3 on Arch Linux (up-to-date as of time of writing) and am 
having an issue figuring out why a particular service fails to run.

The message I am getting is "Job for teamviewerd.service failed because a configured 
resource limit was exceeded." but how do I figure out WHICH resource limit is 
causing this?

What I have tried:

1) checking "systemctl status teamviewerd.service" and "journalctl -xe" as 
mentioned by systemd
2) bumping up the various LimitXXX configuration items in the unit file
3) adding Environment=SYSTEMD_LOG_LEVEL=debug to the unit file

All in vain.

However running the ExecStart line manually using sudo works fine.

The fact that this is teamviewer really doesn't matter - it just happened to be 
where I noticed it, but providing additional info on this error would be very 
welcome.

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