On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> > wrote:
> > > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > > +
> > > + skb =
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > +
> > + skb = alloc_skb(size, GFP_ATOMIC);
> > + if (!skb) {
> > +
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
wrote:
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
wrote:
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size,
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
> * jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> > Please crosspost on netdev - you should know that by now;->
> >
> > I actually disagreee with Herbert on this. Theres definetely good
> > need to have a more usable
* jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> Please crosspost on netdev - you should know that by now;->
>
> I actually disagreee with Herbert on this. Theres definetely good
> need to have a more usable messaging system that rides on top of
> netlink. It is not that netlink cant be extended (I
On Sun, 2005-04-10 at 10:56, James Morris wrote:
> On 10 Apr 2005, jamal wrote:
>
> > Thats what the original motivation for konnector was. To make it easy
> > for joe dumbass.
>
> Who you really want writing kernel code :-)
Ok, let me take that back then ;->
The value is in allowing people who
On 10 Apr 2005, jamal wrote:
> Thats what the original motivation for konnector was. To make it easy
> for joe dumbass.
Who you really want writing kernel code :-)
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Evgeniy,
Please crosspost on netdev - you should know that by now;->
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic) - its
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf <[EMAIL PROTECTED]> wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> > --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> > +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> > @@ -747,7
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> @@ -747,7 +747,7 @@
> if (p->exclude_sk == sk)
> goto out;
>
> -
On Sun, 10 Apr 2005 15:37:57 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> The second one is a huge monster that can not be used in embedded
> systems, calling userspace process from inside the kernel is
> now very flexible way.
is NOT very flexible way...
Evgeniy Polyakov
Only
On Sun, 10 Apr 2005 13:08:44 +0200
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
> > On Sun, 10 Apr 2005 19:52:54 +1000
> > Herbert Xu <[EMAIL PROTECTED]> wrote:
> > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > User should
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
> On Sun, 10 Apr 2005 19:52:54 +1000
> Herbert Xu <[EMAIL PROTECTED]> wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > User should not know about low-level transport -
> > > it is like socket layer - write only data
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please add netdev to the CC list since this discussion pertains to
> the networking subsystem.
>
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > User should not know about low-level transport -
> > it is like
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> User should not know about low-level transport -
> it is like socket layer - write only data and do not care about
> how it will be delivered.
The
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level transport -
it is like socket layer - write only data and do not care about
how it will be delivered.
The delineation
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level transport -
it is like socket layer -
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level transport -
it is like socket layer - write only data and do not care
On Sun, 10 Apr 2005 13:08:44 +0200
Kay Sievers [EMAIL PROTECTED] wrote:
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level
On Sun, 10 Apr 2005 15:37:57 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
The second one is a huge monster that can not be used in embedded
systems, calling userspace process from inside the kernel is
now very flexible way.
is NOT very flexible way...
Evgeniy Polyakov
Only
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
--- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
+++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
@@ -747,7 +747,7 @@
if (p-exclude_sk == sk)
goto out;
- if
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf [EMAIL PROTECTED] wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
--- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
+++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
@@ -747,7 +747,7 @@
Evgeniy,
Please crosspost on netdev - you should know that by now;-
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic) - its
On 10 Apr 2005, jamal wrote:
Thats what the original motivation for konnector was. To make it easy
for joe dumbass.
Who you really want writing kernel code :-)
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Sun, 2005-04-10 at 10:56, James Morris wrote:
On 10 Apr 2005, jamal wrote:
Thats what the original motivation for konnector was. To make it easy
for joe dumbass.
Who you really want writing kernel code :-)
Ok, let me take that back then ;-
The value is in allowing people who are
* jamal [EMAIL PROTECTED] 2005-04-10 10:39
Please crosspost on netdev - you should know that by now;-
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
* jamal [EMAIL PROTECTED] 2005-04-10 10:39
Please crosspost on netdev - you should know that by now;-
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging
On Thu, Apr 07, 2005 at 11:02:22PM -0700, David S. Miller wrote:
> On Fri, 08 Apr 2005 09:19:39 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > I know, the same thing holds for most architectures, including i386.
> > > However, this is not an issue for uni-processor kernels anywhere
On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote:
> On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
>
> > > > Sure, but seems I need to ask again: What is the exact reason not to
> > > > implement
> > > > the muticast message multiplexing/subscription part of the connector as
> > > > a
> > > >
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
> > >
> > > > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > > > sync in
On Fri, 08 Apr 2005 09:19:39 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > I know, the same thing holds for most architectures, including i386.
> > However, this is not an issue for uni-processor kernels anywhere else,
> > so what's so special about MIPS?
>
> Does i386 or ppc has cached
On Fri, 08 Apr 2005 09:19:39 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I know, the same thing holds for most architectures, including i386.
However, this is not an issue for uni-processor kernels anywhere else,
so what's so special about MIPS?
Does i386 or ppc has cached and
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote:
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
Sure, but seems I need to ask again: What is the exact reason not to
implement
the muticast message multiplexing/subscription part of the connector as
a
generic part of
On Thu, Apr 07, 2005 at 11:02:22PM -0700, David S. Miller wrote:
On Fri, 08 Apr 2005 09:19:39 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
I know, the same thing holds for most architectures, including i386.
However, this is not an issue for uni-processor kernels anywhere else,
so
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
> > > Sure, but seems I need to ask again: What is the exact reason not to
> > > implement
> > > the muticast message multiplexing/subscription part of the connector as a
> > > generic part of netlink? That would be nice to have and useful for other
>
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
> >
> > > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > > sync in atomic_sub_return?
> >
> > Sync synchornizes cached mamory access,
> > without it
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
>
> > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > sync in atomic_sub_return?
>
> Sync synchornizes cached mamory access,
> without it new value may be stored only into cache,
> but not into memory.
I
On Fri, 2005-04-08 at 14:53 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
> >
> > > > Unfortunately not, that sync is required exactly for return value store.
> > >
> > > On UP?
> >
> > Yes, some quotes:
>
> Yes but what will go wrong on
On Fri, 8 Apr 2005 14:53:02 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Yes but what will go wrong on uni-processor MIPS when you don't do the
> sync in atomic_sub_return?
Indeed. I see nothing in those quotes which indicate that the
SYNC is needed on uniprocessor. It's only saying things
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
>
> > > Unfortunately not, that sync is required exactly for return value store.
> >
> > On UP?
>
> Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Cheers,
--
On Fri, 2005-04-08 at 14:17 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
> >
> > > > On UP do not.
> > >
> > > Shouldn't we should be fixing the MIPS implementation of
> > > atomic_sub_return to not do the sync on UP then?
> >
> > Unfortunately
On Fri, 08 Apr 2005 07:52:34 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> sparc64 has 32->64 conversation on exit.
It's extremely cheap, the conversion instruction
pairs with the retl instruction so it's essentially
free.
Talking about an arithmetic instruction over is complete
nonsense
On Fri, 8 Apr 2005 14:17:24 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On UP?
I think the barrier can be eliminated on MIPS on UP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
>
> > > On UP do not.
> >
> > Shouldn't we should be fixing the MIPS implementation of
> > atomic_sub_return to not do the sync on UP then?
>
> Unfortunately not, that sync is required exactly for return value store.
On UP?
--
On Fri, 2005-04-08 at 14:02 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
> >
> > > > mips has additional sync.
> > >
> > > But atomic_dec + 2 barries is going to do the sync as well, no?
> >
> > On UP do not.
>
> Shouldn't we should be fixing the
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
>
> > > mips has additional sync.
> >
> > But atomic_dec + 2 barries is going to do the sync as well, no?
>
> On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
On Fri, 2005-04-08 at 13:50 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> > On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > > On Fri, 2005-04-08 at 12:59 +1000,
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > > Evgeniy Polyakov <[EMAIL PROTECTED]>
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > atomic_dec_and_test() is more expensive than 2
On Thu, 2005-04-07 at 11:47 -0400, James Morris wrote:
> On Thu, 7 Apr 2005, Kay Sievers wrote:
>
> > Sure, but seems I need to ask again: What is the exact reason not to
> > implement
> > the muticast message multiplexing/subscription part of the connector as a
> > generic part of netlink? That
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > > but in case of connector I think the
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > but in case of connector I think the price is not so high.
>
> Can you list the platforms on which this is true?
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email:
On Thu, 7 Apr 2005, Kay Sievers wrote:
> Sure, but seems I need to ask again: What is the exact reason not to implement
> the muticast message multiplexing/subscription part of the connector as a
> generic part of netlink? That would be nice to have and useful for other
> subsystems too as an
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote:
> Sure, but seems I need to ask again: What is the exact reason not to implement
> the muticast message multiplexing/subscription part of the connector as a
> generic part of netlink? That would be nice to have and useful for other
>
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
> On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > > The main idea was to simplify userspace control and
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
> On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > > The main idea was to simplify userspace control and notification
> > > system - so people did not waste it's time
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > 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
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
> On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> > The main idea was to simplify userspace control and notification
> > system - so people did not waste it's time learning how skb's are
> > allocated
> > and processed, how socket
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
> The main idea was to simplify userspace control and notification
> system - so people did not waste it's time learning how skb's are
> allocated
> and processed, how socket layer is designed and what all those
> netlink_* and NLMSG* mean
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >
> > 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
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
On Thu, 2005-04-07 at 11:53 +0400, Evgeniy Polyakov wrote:
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> 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
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
On Thu, 2005-04-07 at 09:36 +0200, Guillaume Thouvenin wrote:
> Hi Evgeniy,
>
> I forgot to put you in the CC of the email so I'm forwarding a post
> about the connector sent on lkml.
Ok, I'm in.
> Best regards,
> Guillaume
> email message attachment, "Forwarded message - Re: connector is
>
On Thu, 2005-04-07 at 09:36 +0200, Guillaume Thouvenin wrote:
Hi Evgeniy,
I forgot to put you in the CC of the email so I'm forwarding a post
about the connector sent on lkml.
Ok, I'm in.
Best regards,
Guillaume
email message attachment, Forwarded message - Re: connector is
missing in
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
On Thu, 2005-04-07 at 11:53 +0400, Evgeniy Polyakov wrote:
Guillaume Thouvenin [EMAIL PROTECTED] 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
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
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
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
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning how skb's are
allocated
and processed, how socket layer is designed and what all those
netlink_* and NLMSG* mean if
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning how skb's are
allocated
and processed, how socket layer is
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
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
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote:
Sure, but seems I need to ask again: What is the exact reason not to implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be nice to have and useful for other
subsystems
On Thu, 7 Apr 2005, Kay Sievers wrote:
Sure, but seems I need to ask again: What is the exact reason not to implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be nice to have and useful for other
subsystems too as an option
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
sparc64,
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
but in case of connector I think the price is not so
On Thu, 2005-04-07 at 11:47 -0400, James Morris wrote:
On Thu, 7 Apr 2005, Kay Sievers wrote:
Sure, but seems I need to ask again: What is the exact reason not to
implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
atomic_dec_and_test() is more expensive than 2 barriers +
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Fri, 2005-04-08 at 13:50 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
mips has additional sync.
But atomic_dec + 2 barries is going to do the sync as well, no?
On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
--
Visit
On Fri, 2005-04-08 at 14:02 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
mips has additional sync.
But atomic_dec + 2 barries is going to do the sync as well, no?
On UP do not.
Shouldn't we should be fixing the MIPS implementation
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
Unfortunately not, that sync is required exactly for return value store.
On UP?
--
Visit
On Fri, 08 Apr 2005 07:52:34 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
sparc64 has 32-64 conversation on exit.
It's extremely cheap, the conversion instruction
pairs with the retl instruction so it's essentially
free.
Talking about an arithmetic instruction over is complete
nonsense when
On Fri, 8 Apr 2005 14:17:24 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
On UP?
I think the barrier can be eliminated on MIPS on UP.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 2005-04-08 at 14:17 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
Unfortunately not, that sync is
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
Unfortunately not, that sync is required exactly for return value store.
On UP?
Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Cheers,
--
Visit
On Fri, 8 Apr 2005 14:53:02 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Indeed. I see nothing in those quotes which indicate that the
SYNC is needed on uniprocessor. It's only saying things such
On Fri, 2005-04-08 at 14:53 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
Unfortunately not, that sync is required exactly for return value store.
On UP?
Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Sync synchornizes cached mamory access,
without it new value may be stored only into cache,
but not into memory.
I know,
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote:
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
Sync synchornizes cached mamory access,
without it new value may
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote:
Sure, but seems I need to ask again: What is the exact reason not to
implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be nice to have and useful for other
subsystems
100 matches
Mail list logo