[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]
On Thu, 2005-04-07 at 11:53 +0400, Evgeniy Polyakov wrote:
> > > Guillaume Thouvenin <> wrote:
> > > >
> > > > Hello,
> > > >
> > > > 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?
> Most of your comments are addressed in 4 patches I sent to you and Greg.
> Others [mostly atomic allocation] are API extensions and will be added.
> 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.

I mean review process - It is low priority task for maintainers,
so can be preempted, no problem.

> Proper w1 notification also requires connector.

From the other point of view - how can someone use the interface, if it
not in the kernel tree?

Main connector idea was not system accounting, but it was designed
so that it can be usefull in other places, like accounting.
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning how skb's are
and processed, how socket layer is designed and what all those
netlink_* and NLMSG* mean if they do not need it.

As you can see in kobject_uevent.c changes - it is significant amount of
that can be removed if connector is used without _any_ advantages for
not using connector.

But, of course the main word is yours, so you still may allow growing
netlink uids and socket allocation all over the place.
P.S. udev may also use it directly - for example with some notification
from ->open() syscall for /dev/something_major_minor and
that "something" does not exist :)
[Ok, I know you do not like it, just an idea]

Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-04-07 10:15    [W:0.067 / U:53.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site