Hi Stephen,
On Tue, 17 Jan 2006, Stephen Hemminger wrote:
[...]
> Also, let's work with the current code. It is a lot easier to let others
> clean it up, if the changes are against the mainline (or -mm) rather than
> having to send it off to get put into yet another git repo.
To make sure we wor
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 15:04:34 -0800
> Also, let's work with the current code. It is a lot easier to let
> others clean it up, if the changes are against the mainline (or -mm)
> rather than having to send it off to get put into yet another git
> repo.
On Tue, 17 Jan 2006 14:55:10 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 17 Jan 2006 21:42:38 +0100
>
> > On Tuesday 17 January 2006 21:31, jamal wrote:
> >
> > > the TIPC tree has been open for months now for review.
> >
> > Tha
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 21:42:38 +0100
> On Tuesday 17 January 2006 21:31, jamal wrote:
>
> > the TIPC tree has been open for months now for review.
>
> That is not how Linux code review works - the code is supposed to get posted
> to the appropiate mailing l
On Tuesday 17 January 2006 21:31, jamal wrote:
> The decision was made at netconf and announcements were made in the
> kernel summit
That's the famous "smoke filled backrooms" where Linux development
shouldn't happen.
> the TIPC tree has been open for months now for review.
That is not how Lin
On Tue, 2006-17-01 at 21:18 +0100, Andi Kleen wrote:
> That is what we have code reviews for - to tell you
> about such things - but somehow you seem to have sneaked your code
> around that.
>
That sounds a little harsh Andi and i know you are a much bigger boy
than you sound above.
The decisio
On Tuesday 17 January 2006 16:04, Jon Maloy wrote:
> There are two good reasons (exuses?) for this: First, the dbg.c code was
> written well before relayfs, so for natural reasons we could not
> consider it back then. Second, at least I wasn't aware of relayfs until
> recently, and I am still no
There are two good reasons (exuses?) for this: First, the dbg.c code was
written well before relayfs, so for natural reasons we could not
consider it back then. Second, at least I wasn't aware of relayfs until
recently, and I am still not sure if and how much the functionalities
overlap. Now t
On Tuesday 17 January 2006 19:58, jamal wrote:
> On Tue, 2006-17-01 at 19:35 +0100, Andi Kleen wrote:
> > On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote:
> > > TIPC got added to 2.6.16-rc1, but needs some work.
> > >
> > > Look at some of the global symbols, from tipc.ko
> > > Standard
On Tue, 2006-17-01 at 19:35 +0100, Andi Kleen wrote:
> On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote:
> > TIPC got added to 2.6.16-rc1, but needs some work.
> >
> > Look at some of the global symbols, from tipc.ko
> > Standard practice is to restrict the namespace of modules to a small
On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote:
> TIPC got added to 2.6.16-rc1, but needs some work.
>
> Look at some of the global symbols, from tipc.ko
> Standard practice is to restrict the namespace of modules to a small
> set of prefixes (like tipc_).
Also it has its own questiona
On Tue, 17 Jan 2006, Stephen Hemminger wrote:
> TIPC got added to 2.6.16-rc1, but needs some work.
>
> Look at some of the global symbols, from tipc.ko
> Standard practice is to restrict the namespace of modules to a small
> set of prefixes (like tipc_).
Yep, we are aware of the problem as Jamal
TIPC got added to 2.6.16-rc1, but needs some work.
Look at some of the global symbols, from tipc.ko
Standard practice is to restrict the namespace of modules to a small
set of prefixes (like tipc_).
How about some cleanup here.
000c T addr_domain_valid
0088 T addr_node_va
13 matches
Mail list logo
