Message-ID: <m1aapcqje4.fsf@fess.ebiederm.org>
Date:	Tue, 27 Jul 2010 22:12:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Greg KH <greg@...ah.com>, Greg KH <gregkh@...e.de>,
	Johannes Berg <johannes@...solutions.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"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

Kay Sievers <kay.sievers@...y.org> writes:

> On Tue, Jul 27, 2010 at 22:53, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> Kay Sievers <kay.sievers@...y.org> writes:
>
>>> It should only be used if it's really needed for known used userspace
>>> interfaces. A few others that got converted already did not need it.
>>
>> Interesting.  The symlink creation is slightly buggy in that it is
>> created after the uevent for device creation has been sent.  Which 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 should
> 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 up
> for compatibility. At that point all stuff will be created at the same
> time.

That part seems reasonable.

>> As for the rest the bus compat code is similar but not quite the same
>> as the class code, so I would be extremely reluctant to deploy it
>> except in extremely limited cases.  Backwards 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 lists
> 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 
appear to be a namespace disaster.

Eric

--
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