From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] Driver-core: Always create class directories fixing the broken network drivers. Date: Sun, 20 Jun 2010 05:29:02 -0700 Message-ID: References: <1275484611.3915.11.camel@jlt3.sipsolutions.net> <1275998127.1899.38.camel@yio.site> <1275998603.3706.118.camel@jlt3.sipsolutions.net> <1276005970.3706.132.camel@jlt3.sipsolutions.net> <1276007174.3706.133.camel@jlt3.sipsolutions.net> <1276009590.3706.135.camel@jlt3.sipsolutions.net> <1276014816.3706.137.camel@jlt3.sipsolutions.net> <1276250151.3640.11.camel@jlt3.sipsolutions.net> <1276507247.3926.13.camel@jlt3.sipsolutions.net> <1277033628.3642.1.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Johannes Berg , Greg KH , netdev To: Kay Sievers Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]:58119 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751108Ab0FTM3N (ORCPT ); Sun, 20 Jun 2010 08:29:13 -0400 In-Reply-To: (Kay Sievers's message of "Sun\, 20 Jun 2010 13\:46\:20 +0200") Sender: netdev-owner@vger.kernel.org List-ID: Kay Sievers writes: > On Sun, Jun 20, 2010 at 13:33, Johannes Berg wrote: >> On Sun, 2010-06-20 at 12:52 +0200, Kay Sievers wrote: >> >>> As mentioned earlier, It's pretty fragile to change things in this >>> area, and I prefer the broken network driver-core interactions to be >>> fixed instead - even when they are more complicated. >> >> Can you _please_ offer a proper way to fix it then? > > Sorry, I have no real experience with the issues created by the > assumption that network driver need to be able to get unloaded while > in use. That's very special, always requires a > compiled-into-the-kernel part of the subsystem, and makes it hard to > work with, as we can not use any of the usual core infrastructure to > solve that. So please look at https://bugzilla.kernel.org/show_bug.cgi?id=16215 That simply creates and destroys the network device as things come and go. I think the bnep case is much more serious because it is real hardware not a testing simulation, and it is the second instance of this. Calling the change broken when I can boot up and run X in that configuration just fine is a vast overstatement. Especially when you don't acknowledge that the device layer is broken. I will agree that insane amounts of backwards compatibility are a good idea. So I will cook up a version of my patch that adds a hack to the device layer to only apply this change to devices of class net. That should save let us postpone the architectural dreams for another day. Eric