[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikYcaZmtvjN1Ah2v2hLcAloLGyhiHPAYLatP5tn@mail.gmail.com>
Date: Thu, 22 Jul 2010 17:30:18 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Greg KH <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <greg@...ah.com>, "Rafael J. Wysocki" <rjw@...k.pl>,
"Maciej W. Rozycki" <macro@...ux-mips.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] Driver-core: Fix bluetooth network device rename
regression
On Thu, Jul 22, 2010 at 16:10, Johannes Berg <johannes@...solutions.net> wrote:
> On Thu, 2010-07-22 at 15:38 +0200, Kay Sievers wrote:
>>
>> Please try to fix these drivers instead, or mark the broken for
>> namespaces, if nobody can fix them right now.
>
> We've tried. Nobody, including you, has been able to suggest how to fix
> it.
I did, and several times. Here are the options again:
- Split the driver in two modules, so the auto-cleanup of the netdev
can be done by the second module when the device is force-unloaded
without taking any references to the code while in use (netdev specif
behavior).
- Move the device cleanup code somehow in the core by adding proper
functions to bus devices, similar to the completely mis-used
device_create() function for class devices. This would also be a
proper fix for the weird driver core use.
- Do not allow to force-unload the module while the netdev is in use.
You would need some "destruct" command for the device then, which
removes the netdev, and to be able to unload the module.
> And it's not just broken with network namespaces enabled either, as
So what's the problem without the sysfs ns then? I didn't hear any the
last couple of years.
> Eric explained. I really don't see why you keep asking us to fix it when
> clearly we cannot -- even you don't know how and you certainly have more
> insight into the device model than we do.
Sure, and I ask again to fix the drivers, instead of sneaking-in dirty
hacks into the core, just by calling an expected behavior a
"regression". This is not a core bug, and should not be worked around
that way in the core.
If there is a new requirement for the core (like possibly point 2
above), we can surely look into making this happen.
We can not add lists of individual subsystems to generic core
functions to work around broken drivers. I hope you will understand
that.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists