<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:kay@vrfy.org" title="Kay Sievers <kay@vrfy.org>"> <span class="fn">Kay Sievers</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED WONTFIX - udev: network device renaming broken"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=53837">bug 53837</a>
        <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>REOPENED
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>WONTFIX
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED WONTFIX - udev: network device renaming broken"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=53837#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED WONTFIX - udev: network device renaming broken"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=53837">bug 53837</a>
              from <span class="vcard"><a class="email" href="mailto:kay@vrfy.org" title="Kay Sievers <kay@vrfy.org>"> <span class="fn">Kay Sievers</span></a>
</span></b>
        <pre>I see only one option and that would be to teach the kernel with an option
to reserve 0-99 or whatever of ethX, so this range can be used by userspace to
rename *to*. That tunable could be set by the system before any kernel module
is loaded.

We will not play the silly games with retry-loops in hotplug paths to
race against the kernel creating new device while we try to rename in
userspace the same thing, and fail.

What we had is not coming back to udev, no matter how many times you
open the bug again. :) If you really care and do the kernel work, all would
just work without racy unreliable loops in udev.

Newer udev versions will not play these wrong games in userspace fighting
*against* the kernel.

I spent far too much time over the years with supporting the fallout of that
bad idea in the first place, and I'll not waste any more time with it.

It just did not work reliably, and never will, and we stopped pretending
to solve problems we cannot solve in that way.

As mentioned, I guess it's a problem that can be solved with help of the
kernel, but not by udev alone.

Closing it again.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>