Re: BUG in: Driver core: convert block from raw kobjects to core devices (fwd)

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, 2007-10-31 at 11:46 -0500, James Bottomley wrote:
> On Wed, 2007-10-31 at 17:42 +0100, Kay Sievers wrote:
> > On Wed, 2007-10-31 at 11:31 -0500, James Bottomley wrote:

> > > Doesn't this circularity now exist for everything?  Every device that
> > > creates a queue has a reference to the queue, every queue has a
> > > reference to its attached gendisk and now every gendisk has a reference
> > > to the device creating the queue?  This doesn't look to be a SCSI
> > > specific problem.
> > 
> > It's only SCSI so far, everything else seems fine.
> 
> But you didn't respond to the stated problem: there are very few other
> non-scsi block devices ... have you tried looking at cciss?

I tried ub instead of usb-storage and sd card driver which is a raw
block driver, i didn't try cciss, or other more advanced blockdev
drivers.

> > But, the real problem is that the core seems to deadlock if two devices
> > reference each other (or build a larger circle), even when they are
> > deleted, that's the problem we are running in.
> 
> Yes ... we sort of evaded that one by having class devices hang off the
> sides of real devices ... making everything a peer with crosslinks
> brings it back with a vengeance.
 
Yeah, which made sysfs a horrible mess as soon as people started putting
hierarchy in class devices. The whole idea of "physical", "virtual", 
"class", "bus" causes nothing but problems in userspace, and exposes
kernel implementation details, which change all the time. There are even
subsystem which moved from class to bus because they need driver
binding. And there is really no point in exposing that to userspace.

It's a design mistake, we try to fix now. We really need a single
classification and a single hierarchy and not the 3 completely different
access rules for 3 types of devices, which don't have any interesting
difference, besides the way the kernel handles them.

Kay