Rainer Weikusat wrote:
> I can neither count on being 'in control of hardware' nor on 'people
> editing configuration files'.
Then apologies, it appears I misunderstood your position.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.o
Simon Hobson writes:
> Rainer Weikusat wrote:
>> That's you're preferred set of workarounds.
>
> I suspect that we're all in "violent agreement" that different users
> (or types of users) have different preferences and priorities. In the
> general case there is definitely an issue to be solved -
Le 23/06/2016 18:33, Rainer Weikusat a écrit :
'Assigning names based on
MAC addresses' is problematic as a MAC address is a typically
programmable property of a NIC.
Yes, *you*, the admin, can change the MAC address. The kernel won't
do it, and the hotplugger will do it only if *you* ed
Rainer Weikusat wrote:
> That's you're preferred set of workarounds.
I suspect that we're all in "violent agreement" that different users (or types
of users) have different preferences and priorities. In the general case there
is definitely an issue to be solved - just different approaches to
Didier Kryn writes:
> Le 23/06/2016 09:05, Simon Hobson a écrit :
>> Rainer Weikusat wrote:
>>
>>> >Reportedly, Linux hotplug already had the same problem.
>> OK, that's what I'd have been seeing in the past then.
>>
>>> >During initialization, the kernel walks through the bus or busses it
>>> >f
Simon Hobson writes:
> Rainer Weikusat wrote:
>
>> Reportedly, Linux hotplug already had the same problem.
>
> OK, that's what I'd have been seeing in the past then.
>
>> During initialization, the kernel walks through the bus or busses it
>> finds in order to locate all devices and enables them
Le 23/06/2016 09:05, Simon Hobson a écrit :
Rainer Weikusat wrote:
>Reportedly, Linux hotplug already had the same problem.
OK, that's what I'd have been seeing in the past then.
>During initialization, the kernel walks through the bus or busses it
>finds in order to locate all devices and
Le 22/06/2016 16:29, Rainer Weikusat a écrit :
If you'll neither believe me nor the code wrt causes these 'random
device names', may I try some kind of authority?
7.4.3.7. Device naming order changes randomly after rebooting
This is due to the fact that Udev, by design, handles
Rainer Weikusat wrote:
> Reportedly, Linux hotplug already had the same problem.
OK, that's what I'd have been seeing in the past then.
> During initialization, the kernel walks through the bus or busses it
> finds in order to locate all devices and enables them by calling the
> responsible dri
Simon Hobson writes:
> Rainer Weikusat wrote:
>> In absences of post hoc driver shuffling, these names *are not*
>> random.
[...]
> You've posted a statement that says drivers are loaded in a
> non-deterministic order. Therefore, in the general case where not all
> interfaces are using the same
Rainer Weikusat wrote:
> In absences of post hoc driver shuffling, these names *are not*
> random. But as that's clearly something you're not willing to believe
> in, this discussion seems pretty pointless.
I think we must be making assumptions about what each other are talking about -
you appe
Simon Hobson writes:
> Rainer Weikusat wrote:
>>> If you just use the default kernel naming scheme then you open
>>> yourself to the problem that udev was designed to solve - that of
>>> random device names.
>>
>> If you'll neither believe me nor the code wrt causes these 'random
>> device names
I wrote:
>> Unless the admin transfers the installation to another system. Assuming
>> that everything used to work fine with eth0 - eth3, all hell will
>> break lose because the sole four interfaces are now called eth4 - eth7.
>
> But the point is, the admin can then, with one simple edit, retur
Rainer Weikusat wrote:
>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names.
>
> If you'll neither believe me nor the code wrt causes these 'random
> device names', may I try some kind of aut
On Wed, Jun 22, 2016 at 10:35:39AM +0200, Stephan Seitz wrote:
> On Wed, Jun 22, 2016 at 08:08:38AM +0100, Simon Hobson wrote:
> >But once you go down the route of udev (or equivalent, eg vdev) and
> >persistent rules, then "eth0" is just a subset of "admin set interface
> >name".
>
> The problem
Didier Kryn writes:
> Le 22/06/2016 09:08, Simon Hobson a écrit :
>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names. I do have personal experience of that - boot
>> with a different disk (fo
Simon Hobson writes:
> Rainer Weikusat wrote:
>
>>> All in all, the easiest way by far is to use stable and user(admin)
>>> set names for interfaces !
>>
>> This is going to bite you in the posterior in case of canned OS
>> installations intended to be usable on a wide range of differently
>> co
Le 22/06/2016 09:08, Simon Hobson a écrit :
If you just use the default kernel naming scheme then you open yourself to the problem that udev was
designed to solve - that of random device names. I do have personal experience of that - boot with a
different disk (for maintenance) and eth0 & eth1
On Wed, Jun 22, 2016 at 08:08:38AM +0100, Simon Hobson wrote:
But once you go down the route of udev (or equivalent, eg vdev) and
persistent rules, then "eth0" is just a subset of "admin set interface
name".
The problem with udev and eth0 is, that you have race conditions if you
let udev rena
Rainer Weikusat wrote:
>> All in all, the easiest way by far is to use stable and user(admin)
>> set names for interfaces !
>
> This is going to bite you in the posterior in case of canned OS
> installations intended to be usable on a wide range of differently
> configured 'servers' and not supp
On Tue, 21 Jun 2016 20:10:24 +0100
Rainer Weikusat wrote:
> The nice thing about free software is that one may use it to solve
> real problems the developers disapprove of.
NICE QUOTE RAINER!!!
SteveT
Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters
Simon Hobson writes:
[...]
> All in all, the easiest way by far is to use stable and user(admin)
> set names for interfaces !
This is going to bite you in the posterior in case of canned OS
installations intended to be usable on a wide range of differently
configured 'servers' and not supposed
Steve Litt wrote:
> Good point. Here in my house, I trust everyone with a physical console,
> so individual computers have simple or no firewalls.
I'm running servers where you have to assume everyone is out to get you.
> My Internet
> firewall is pFSense, and every once in a while I use OpenBS
On Tue, 21 Jun 2016 08:14:57 +0100
Simon Hobson wrote:
> Steve Litt wrote:
>
> > Of all the escapades of FreeDesktop.Org, managers of Lennart and the
> > Redhats, these name thingies are some of the least onerous. I put a
> > shellscript on the list a few months ago that delivers the wifi
> > d
Steve Litt wrote:
> Of all the escapades of FreeDesktop.Org, managers of Lennart and the
> Redhats, these name thingies are some of the least onerous. I put a
> shellscript on the list a few months ago that delivers the wifi device
> name, and that script can be used in init scripts and the like.
On Mon, 20 Jun 2016 09:26:56 +0100
Simon Hobson wrote:
> Rainer Weikusat wrote:
>
> > This is published here in the hope that it is useful for someting.
> >
> > The basic design of udev is similar to that of a forking server:
> > There's a parent process listening for uevents from the kernel o
Rainer Weikusat wrote:
> This is published here in the hope that it is useful for someting.
>
> The basic design of udev is similar to that of a forking server: There's
> a parent process listening for uevents from the kernel on a netlink
> socket which passes these events to worker processes fo
This is published here in the hope that it is useful for someting.
The basic design of udev is similar to that of a forking server: There's
a parent process listening for uevents from the kernel on a netlink
socket which passes these events to worker processes for actual
processing. In case no idl
28 matches
Mail list logo
