From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] Driver-core: Fix bluetooth network device rename regression Date: Tue, 27 Jul 2010 22:12:51 -0700 Message-ID: References: <1279822828.12439.24.camel@jlt3.sipsolutions.net> <20100722182827.GA12821@suse.de> <1279823801.12439.31.camel@jlt3.sipsolutions.net> <20100722185449.GB528@suse.de> <20100726180941.GB4883@kroah.com> <20100727134904.GA4994@kroah.com> <20100727183624.GB30363@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Greg KH , Greg KH , Johannes Berg , Andrew Morton , "Rafael J. Wysocki" , "Maciej W. Rozycki" , netdev To: Kay Sievers Return-path: Received: from out01.mta.xmission.com ([166.70.13.231]:42852 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514Ab0G1FNF convert rfc822-to-8bit (ORCPT ); Wed, 28 Jul 2010 01:13:05 -0400 In-Reply-To: (Kay Sievers's message of "Wed\, 28 Jul 2010 06\:41\:52 +0200") Sender: netdev-owner@vger.kernel.org List-ID: Kay Sievers writes: > On Tue, Jul 27, 2010 at 22:53, Eric W. Biederman wrote: >> Kay Sievers writes: > >>> It should only be used if it's really needed for known used userspa= ce >>> interfaces. A few others that got converted already did not need it= =2E >> >> Interesting. =C2=A0The symlink creation is slightly buggy in that it= is >> created after the uevent for device creation has been sent. =C2=A0Wh= ich can >> lead to some interesting races in userspace. > > At uevent time the 'subsystem' is specified by the 'sybsystem' link > and the SUBSYSTEM property in the event environment. The device shoul= d > not really rely on finding itself linked in class. The class and bus > link collections are only to find a group of devices of the same > subsystem, and this should not be a real world problem here. I agree that there should be no real world problems. The bottom line is that every sysfs attribute should be created before we send the uevent or else we get horribly subtle races or we get user space code that starts looping looking for the interface. > Also there are plans to merge struct class and struct bus_type > completely and keep only a few flags around where stuff should show u= p > for compatibility. At that point all stuff will be created at the sam= e > time. That part seems reasonable. >> As for the rest the bus compat code is similar but not quite the sam= e >> as the class code, so I would be extremely reluctant to deploy it >> except in extremely limited cases. =C2=A0Backwards compatibility is >> important, and we should strive our best to maintain backwards >> compatibility it for the kernel<->userspace ABIs. > > Today, the only real difference between class and bus devices are > these 'collection links', the devices otherwise look completely the > same. There should be no important difference. I don't see the class subdirectories created for bus devices, and I don't see any equivalent. At least for the network devices this is a huge difference, because the device namespace is controlled by userspace and it is NOT ok to have namespace conflicts with arbitrary sysfs attributes. > Buses are very much preferred over classes today, no new stuff should > create any class. The bus directories are extendable and have a > reasonable layout with the devices/ subdirectory, unlike the flat > class directories where people got the silly idea to mix devices list= s > with attributes to confuse everything. Which is generally reasonable. However busses appear to have the silly idea that it is ok to mix child child device lists of different kinds of children with attributes and confuse everything. At the subsystem level bus devices look better. At the individual device level bus devices stacked on bus devices=20 appear to be a namespace disaster. Eric