Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

On Thu, 2005-04-07 at 00:58 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> >
> > > > >  I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it
> > > > > seems that you removed the connector?
> > > > 
> > > > Greg dropped it for some reason.  I think that's best because it needed a
> > > > significant amount of rework.  I'd like to see it resubitted in totality so
> > > > we can take another look at it.
> > 
> > Hmm, what exactly do you think _must_ be changed?
> 
> The stuff we discussed.
> 
> Plus, I'm still quite unsettled about the whole object lifecycle
> management, refcounting and locking in there.  The fact that the code is
> littered with peculiar barriers says "something weird is happening here",
> and it remains unobvious to me why such a very common kernel pattern was
> implemented in such an unusual manner.
> 
> So.  I'd like to see the whole thing reexplained and resubmitted so we can
> think about it all again.

All those barriers can be replaced with atomic_dec_and_test(), 
i.e. with something that returns the value.
Methods that return value requires explicit barriers.

Actually there are quite many places where we have:

cpu0                             cpu1
use object
atomic_dec()
                                 if atomic_read/atomic_dec_and_test == 0
                                    free object.

With explicit barriers about use object we can
not catch atomic vs. non atomic reordering.
There still _may_ exist other types of races, 
but as we discussed, in connector case they 
were my faults [flush on connector removal].

> > Most of your comments are addressed in 4 patches I sent to you and Greg.
> 
> Which comments were not addressed?

CBUS code comments [I did not get ack on CBUS itself], and two below
issues.

> > Others [mostly atomic allocation] are API extensions and will be added.
> 
> I would like to see that code before committing to merging anything.

Ok.

> > There also not included flush on callback removal.
> >
> > > > It's a new piece of core kernel infrastructure and the barriers for that
> > > > are necessarily high.
> > > > 
> > > > > Will you include it again in futur
> > > > > release? At the same time, will you include the fork connector?
> > > > 
> > > > I could put the fork connector into -mm, but would like to be convinced
> > > > that it's acceptable to and useful for all system accounting requirements,
> > > > not just the one project.  That means code, please.
> > 
> > SuperIO and kobject_uevent are also dropped as far as I can see.
> > 
> > Acrypto is being reviewed but it also depends on it, although 
> > it takes to much time, probably will be dropped too.
> > 
> > Proper w1 notification also requires connector.
> 
> Guillaume was referring to "fork connector", not to "connector".

fork connector depends on the dropped connector/CBUS.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]