From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753946AbcALUpy (ORCPT ); Tue, 12 Jan 2016 15:45:54 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:53858 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753145AbcALUpw (ORCPT ); Tue, 12 Jan 2016 15:45:52 -0500 Date: Tue, 12 Jan 2016 15:45:50 -0500 (EST) Message-Id: <20160112.154550.2297969991865269932.davem@davemloft.net> To: jay.vosburgh@canonical.com Cc: lkundrak@v3.sk, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, vfalico@gmail.com, gospo@cumulusnetworks.com Subject: Re: [PATCH 3/3] bonding: make device count build-time configurable From: David Miller In-Reply-To: <8166.1452616452@famine> References: <1452599916-27511-1-git-send-email-lkundrak@v3.sk> <8166.1452616452@famine> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 12 Jan 2016 12:45:52 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jay Vosburgh Date: Tue, 12 Jan 2016 08:34:12 -0800 > Lubomir Rintel wrote: > >>The devices can be created at run-time for quite some time already and the >>load-time device creation collides with attempts to create the device of >>the same name: >> >> # rmmod bonding >> # ip link add bond0 type bond >> RTNETLINK answers: File exists >> >>This is pretty much the same situation as was with the block loop devices >>which was solved by adding a build-time configuration that the >>distributions could use as they deem fit while keeping the default for >>compatibility. > > I agree this is annoying, but I would expect distros to leave > this set to 1 (for backwards compatibility with scripts that "modprobe > bonding" then assume bond0 exists). This leaves the problem in place > for the vast majority of users. > > Is there a reasonable way to resolve this that would actually > fix things for regular distro kernel users? Yeah I personally don't like this at all. This behavior has 2 decades of precedence, it's therefore hard coded into deep dark nooks and cranies of people's scripts. Just be content with how things are, and document it better if need be.