lkml.org 
[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
From
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-04-07 10:25    [W:0.081 / U:12.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site