From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: netdev@oss.sgi.com, Greg KH <greg@kroah.com>,
Jamal Hadi Salim <hadi@cyberus.ca>,
Kay Sievers <kay.sievers@vrfy.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
James Morris <jmorris@redhat.com>,
Guillaume Thouvenin <guillaume.thouvenin@bull.net>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Thomas Graf <tgraf@suug.ch>, Jay Lan <jlan@engr.sgi.com>
Subject: Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next.
Date: Tue, 10 May 2005 14:04:45 +0400 [thread overview]
Message-ID: <20050510140445.36cc15cb@zanzibar.2ka.mipt.ru> (raw)
In-Reply-To: <200505100118.48027.dtor_core@ameritech.net>
On Tue, 10 May 2005 01:18:46 -0500
Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> On Monday 11 April 2005 07:59, Evgeniy Polyakov wrote:
> > /*****************************************/
> > Kernel Connector.
> > /*****************************************/
> >
> > Kernel connector - new netlink based userspace <-> kernel space easy to use communication module.
> >
>
> Hi Evgeniy,
Hello, Dmitriy.
> I have looked at the connector implementation one more time and I think
> it can be improved in the following ways:
>
> - drop unneeded refcounting;
It is already.
> - start only one workqueue entry instead of one for every callback type;
There is only one queue per callback device.
> - drop cn_dev - there is only one connector;
There may be several connectors with different socket types.
I use it in my environment for tests.
> - simplify cn_notify_request to carry only one range - it simplifies code
> quite a bit - nothing stops clientd from sending several notification
> requests;
? Nothing stops clients from sending several notification requests now.
I do not see how it simplifies the things?
Feel free to set idx_num and val_num to 1 and you will have the same.
> - implement internal queuefor callbacks so we are not at mercy of scheduler;
Current implementation has big warning about such theoretical behaviour,
if it will be triggered, I will fix that behaviour,
more likely not by naive work allocation - there might be
at least cache/memory pool or something...
> - admit that SKBs are message medium and do not mess up with passing around
> destructor functions.
You mess up layers.
I do not see why you want it.
> - In callback notifier switch to using GFP_KERNEL since it can sleep just
> fine;
Yes, it is correct
> - more...
>
> Because there were a lot of changes I decided against doing relative patch
> but instead a replacement patch for affected files. I have cut out cbus and
> documentation to keep it smaller so it will be easier to review. The patch
> is compile-tested only.
Connector with your changes just does not work.
Dmitry, I do not understand why do you change things in so radical manner,
especially when there are no 1. new interesting features, 2. no performance
improvements, 3. no right design changes.
> BTW, I do not think that "All rights reserved" statement is applicable/
> compatible with GPL this software is supposedly released under, I have
> taken liberty of removing this statement.
You substitute license agreements with copyright.
"All rights reserved" is targeted to copyright
(avtorskoe pravo, zakon N 5351/1-1) of the code
and has nothing with license.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
next prev parent reply other threads:[~2005-05-10 10:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 12:59 Evgeniy Polyakov
2005-04-11 13:32 ` Thomas Graf
2005-04-11 14:49 ` [2/1] " Evgeniy Polyakov
2005-04-26 15:57 ` [1/1] " Dmitry Torokhov
2005-04-26 16:24 ` Evgeniy Polyakov
2005-04-26 16:30 ` Evgeniy Polyakov
2005-04-26 17:34 ` Dmitry Torokhov
2005-04-26 18:07 ` Evgeniy Polyakov
2005-04-26 18:20 ` Dmitry Torokhov
2005-04-26 18:31 ` Evgeniy Polyakov
2005-04-26 18:42 ` Dmitry Torokhov
2005-04-26 18:48 ` Evgeniy Polyakov
2005-04-26 19:06 ` Dmitry Torokhov
2005-04-26 19:28 ` Evgeniy Polyakov
2005-04-26 20:02 ` Dmitry Torokhov
2005-04-27 4:06 ` Evgeniy Polyakov
2005-04-27 5:16 ` Dmitry Torokhov
2005-04-27 5:32 ` Evgeniy Polyakov
2005-04-27 5:46 ` Dmitry Torokhov
2005-04-27 6:08 ` Evgeniy Polyakov
2005-04-26 17:31 ` Dmitry Torokhov
2005-04-26 18:03 ` Evgeniy Polyakov
2005-04-26 18:10 ` Evgeniy Polyakov
2005-04-26 18:13 ` Evgeniy Polyakov
2005-04-26 18:25 ` Dmitry Torokhov
2005-04-26 18:35 ` Evgeniy Polyakov
2005-05-10 6:18 ` Dmitry Torokhov
2005-05-10 10:04 ` Evgeniy Polyakov [this message]
2005-05-10 14:56 ` Dmitry Torokhov
2005-05-10 15:41 ` Evgeniy Polyakov
2005-05-10 17:50 ` Dmitry Torokhov
2005-05-10 18:24 ` Evgeniy Polyakov
2005-05-11 5:46 ` Dmitry Torokhov
2005-05-11 6:48 ` Evgeniy Polyakov
2005-05-11 14:09 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050510140445.36cc15cb@zanzibar.2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=akpm@osdl.org \
--cc=dtor_core@ameritech.net \
--cc=greg@kroah.com \
--cc=guillaume.thouvenin@bull.net \
--cc=hadi@cyberus.ca \
--cc=herbert@gondor.apana.org.au \
--cc=jlan@engr.sgi.com \
--cc=jmorris@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®