Messages in this thread | | | Subject | Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1] | From | Evgeniy Polyakov <> | Date | Thu, 07 Apr 2005 12:23:52 +0400 |
| |
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] | |