On Thu, 2005-04-07 at 00:58 -0700, Andrew Morton wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
