Hi Lennart,
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.
Well, this is something we can fix by documentation, no?
Or maybe name the match option differently,
On 5 Dec 2014 10:07, Marcel Holtmann mar...@holtmann.org wrote:
Hi Lennart,
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.
Well, this is something we can fix
On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote:
Hi Lennart,
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.
Well, this is something we
On Fri, Dec 5, 2014 at 2:21 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 05.12.14 10:07, Marcel Holtmann (mar...@holtmann.org) wrote:
Hi Lennart,
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort
On Thu, Dec 4, 2014 at 3:50 AM, Lennart Poettering
lenn...@poettering.net wrote:
Tom, I think it would make sense to allow Name= matches in the [Match]
section of .link files, no?
Hm, so far I hesitated, as the most common scenarios is the one that
William has, namely to want to match on the
On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
I mean, most of the times .link files are
used to choose the name depending on other fields, but I think in all
cases where the name is chosen at creation time of an interface (like
for example for veth links), it should be Ok to
On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
I mean, most of the times .link files are
used to choose the name depending on other fields, but I think in all
cases where the name is chosen at
On Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.
Well, this is something we can fix by documentation,
On Thu, Dec 4, 2014 at 8:08 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:
Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
In regards to the OS and syntax, this is NixOS. NixOS uses its own
expression language to configure the entire system, including the network
stack. If a user wanted to configure their system's networking stack, they
would modify the networking.* set of options in their
Thanks for the links William. Looks like most of that should be
covered by networkd. I now also added support for MTU and MACAddress
to be set in the .network files. The intention here is that if you
ever disable a network at runtime, we will revert to the default
(.link-defined) settings.
Yes, we could support a [Link] section in .network files applying such
settings per network. Though that this should really be about overriding
the link specific settings, so not sure it fits your usecase precisely...
On 24 Nov 2014 20:46, William Kennington will...@wkennington.com wrote:
I'd
On Mon, 24.11.14 11:46, William Kennington (will...@wkennington.com) wrote:
I'd like to be able to set the MAC Address and MTU of interfaces, with just
the interface name alone. The current method for matching links seems to be
heavily tied to udev ATTRs and I understand given the nature of
13 matches
Mail list logo
