On Thu, Jul 22, 2010 at 19:18, Eric W. Biederman [off-list ref] wrote:

Kay Sievers [off-list ref] writes:

Let me get this straight.  You believe a non-trival non-obvious
complete rewrite of entire subsystems after rc1 is better than
a one line bug fix that let's real hardware work for real
people?

Yes. The drivers are broken in its core use pattern, and enabling a
(non-common) new feature exposes this. Users should just not enable
the new feature until the drivers, they might depend on, are fixed
properly. That's the rule for all other kernel development too, and I
don't see what's different here. It's not a regression, and not a bug
in the core, which needs fixing.

I don't see what would justify subsystem-specific hacks in the core,
which we will never be able to remove. Your patch exposes sysfs device
layout for a single subsystem in an unusual manner, and we can not
change that later. We need to avoid such special cases for all
reasons.

You have had 3 years to do better a better job with the bluetooth
driver.

I don't know of any real-world problem here.

Furthermore we fixed the rest of this regression in the core I don't
see why we can fix the entirety of it this namespace regression in the
core.  Especially since it is an obviously correct one line change.

Oh, no. It's obviously wrong to add specific lists of subsystems to
generic core code to fix individual drivers. It even implements its
own sysfs layout rules for a single subsystem.

Please help fixing the drivers, or improving the core where needed, to
support these drivers better, but don't try to throw quick and dirty
and wrong fixes at us. Sysfs is already hard to understand and more
exceptions like this, and subsystem-specific layout rules would
seriously be the wrong direction.

Thanks,
Kay