On Sat, 4 Aug 2007, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Aug 2007, Stefan Richter wrote:
There is a variety of possible naming schemes:
- Naming by order of discovery.
- Naming by vendor/model name strings.
- Naming by universally unique identifier.
- Naming by topolog
[EMAIL PROTECTED] wrote:
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>> There is a variety of possible naming schemes:
>>
>> - Naming by order of discovery.
>> - Naming by vendor/model name strings.
>> - Naming by universally unique identifier.
>> - Naming by topology.
>> - ...
>>
>> Only the
On Fri, 3 Aug 2007, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
It does not rename ethX to the "next free" one, but to a _persistent_ one.
If it were a "next free" thing, then removing
[EMAIL PROTECTED] wrote:
> On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
>> On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
>>> It does not rename ethX to the "next free" one, but to a _persistent_ one.
>>> If it were a "next free" thing, then removing a card would shuffle all
>>> your
On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
It does not rename ethX to the "next free" one, but to a _persistent_ one.
If it were a "next free" thing, then removing a card would shuffle all
your eth around again (and invalidate your
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
> It does not rename ethX to the "next free" one, but to a _persistent_ one.
> If it were a "next free" thing, then removing a card would shuffle all
> your eth around again (and invalidate your iptables rules at the same
> time, to no
On Thu, Aug 02, 2007 at 05:36:45PM +0400, Michael Tokarev wrote:
> not become required (it is slowly becoming - for example, some
> packages on Debian (like xen for example) now explicitly depends
> on udev - but so far I managed to satisfy this dependency by
> other means).
udev is not problem -
> >And now tell me please how can I connect two messages from dmesg:
> >eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express)
> >10/100/1000Base-T Ethernet 00:14:5e:5d:18:26
> >nic10: Link is up at 100 Mbps, full duplex.
>
> Generally, the "link is xyz" message comes directly after loa
Jan Engelhardt wrote:
> On Aug 2 2007 16:56, Michael Tokarev wrote:
I already can see comments from udev/sysfs maintainers here: "naming
is a policy which does not belong to kernel". It's a bullshit, because
kernel too has to use SOME way to name things,
>>> (1) The kernel starts wi
On Aug 2 2007 16:56, Michael Tokarev wrote:
>>> I already can see comments from udev/sysfs maintainers here: "naming
>>> is a policy which does not belong to kernel". It's a bullshit, because
>>> kernel too has to use SOME way to name things,
>>
>> (1) The kernel starts with ethX
>> (2) udev ren
Jan Engelhardt wrote:
> On Aug 2 2007 15:23, Michael Tokarev wrote:
>> Herbert Rosmanith wrote:
On Aug 2 2007 12:42, Herbert Rosmanith wrote:
There never *were* days when eth0 remained eth0 across such changes.
>> []
>>> of course, that's problem with gentoo, not with the kernel.
>> To me
On Aug 2 2007 15:23, Michael Tokarev wrote:
>Herbert Rosmanith wrote:
>>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>>> There never *were* days when eth0 remained eth0 across such changes.
>[]
>> of course, that's problem with gentoo, not with the kernel.
>
>To me it'd be a problem, but I don'
Herbert Rosmanith wrote:
>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>> There never *were* days when eth0 remained eth0 across such changes.
[]
> of course, that's problem with gentoo, not with the kernel.
Whenever it's a problem or not is questionable too. I mean,
ethX order depends on modu
13 matches
Mail list logo
