Re: [systemd-devel] lunch before devconf
Update: The location is now known: Purkyňova 99. We're crowdsourcing some topics to discuss so we're not bored ;) Please add to the list: https://docs.google.com/document/d/1y4NU60q0oCHGAo3qi0NkK5KVLdQRY-ZLSUroqrUT-XE/edit?usp=sharing Zbyszek On Thu, Jan 09, 2020 at 04:06:27PM +, Zbigniew Jędrzejewski-Szmek wrote: > Dear all, > > we'll be having an open meeting in Brno on Thursday, Jan 23rd, 2020, > before the DevConf.cz conference. Everyone interested in systemd > development is invited. The plan is to meet for lunch around 1 PM, and > then go the Red Hat office afterwards for discussion and planning. > We should be at the office from 2PM and it is of course also possible > to go directly there. > > When: 23.1.2020, Thursday, 13:00 – 16:00. > Location: Red Hat offices in Brno, > Purkyňova 99 or 111 depending on availability (14:00–16:00) > and somewhere close for lunch (13:00—14:00). > > If you wish to join, please let me know (off-list), so I can keep tabs. > Once we know the exact location, I'll reply to this email with additional > details. > > Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Better network naming on Hyper-V/Azure?
> -Original Message- > From: Lennart Poettering > Sent: Monday, January 13, 2020 4:18 AM > To: Haiyang Zhang > Cc: Stephen Hemminger ; systemd- > de...@lists.freedesktop.org; Michael Kelley > Subject: Re: [systemd-devel] Better network naming on Hyper-V/Azure? > > On Fr, 10.01.20 16:17, Haiyang Zhang (haiya...@microsoft.com) wrote: > > > > My guess is that this is a lot like SR-IOV slot number that we can > > > already use to name interfaces, right? If so, supporting things the > > > same way sounds totally OK. > > > > Thanks for your explanation. We do want to use the ethN format, and want > the > > results to be the same between Async and sync probing > > Then deal with it in the kernel. Allocating from the same ethN > namespace is always going to be racy if both kernel and userspace do > it. > > That's why the names userspace generally picks for stable Ethernet > interfaces start with "en" followed by some stable suffix of a kind, > under the assumption the kernel will not allocate from that namespace. > > > @Stephen Hemminger Since systemd needs to avoid stepping into the kernel > > ethN formatting, should we do the synthetic NIC naming inside kernel (netvsc > > driver)? > > If you have any other driver register network interfaces on your > kernel than your whole enumeration will go wrong though. If you > tightly control which drivers exist in your environment you might get > away with taking ownership of the ethN namespace entirely from your > own driver and manage it fully. Thanks for your suggestions! So my implementation will keep the naming in kernel driver (netvsc). 1) The netvsc's probe_type will be set to PROBE_DEFAULT_STRATEGY, so user can either continue with the current sync-probing by default, or use module/kernel cmdline option to enable Async-probing if other devices, such as DDA or SRIOV/VF NICs are configured to be named in different space (enP*, etc.) by systemd. 2) If Async-probing option is in use, netvsc driver will use the dev_num based on VMBus offer sequence. It will be the smallest available ethN format, which is the same result as the current sync-probing result. 3) My proposal is that Async probing has the same naming as sync probing. In case of hot add/remove, the names may be reused. The names may change after hot add/remove then reboot once. But the names will be stable in further reboots. It is the same behavior as current code (sync probing). Thanks, - Haiyang ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EXT :Re: Systemd udev add tag for boot device
Lennart,
Is it not possible for a udev rule like the following to work? MYVAR has been
imported (with value sda) and is visible for the block device. I verified it
with udevadm info --query=name -x sda.
KERNEL=="%E{MYVAR}", TAG+="test"
The end result is that this rule doesn't fire. Could someone explain why?
According to the man pages, I think this should work.
Kind Regards,
Kevin
-Original Message-
From: Lennart Poettering
Sent: Monday, January 13, 2020 10:54 AM
To: Boyce, Kevin P [US] (AS)
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: EXT :Re: [systemd-devel] Systemd udev add tag for boot device
On Mo, 13.01.20 09:10, Boyce, Kevin P. (AS) (kevin.bo...@ngc.com) wrote:
> Thank you Lennart.
>
> I'm thinking I will create my own sort of "built-in" command that can
> parse /proc/cmdline to look for the root= variable early in udev rules
> so I can create the tag.
So, systemd has to for determining the backing file system of some directory
and this is used by gpt-auto-generator for finding the block device backing /
or /usr/. I figure you want something like that?
We don't expose that directly though, and it's limited, since we do not cover
complex storage. We do cover btrfs though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
