> The only thing that was not clear to me from reviewing the module
> namespace stuff a while ago was the original intent, but I confess I
> actually only looked at the technical details to see if it was
> applicable to the backports case, do you recall the original
> motivation ?
The original
On Wed, Nov 5, 2014 at 3:09 PM, Andi Kleen wrote:
>> You know, this use case seems unavoidable so I'll just proceed with the
>> configurability of it. But note that it seems we're both in agreement
>> that right now what you described requires more work before in any way
>> shape or form folks
> You know, this use case seems unavoidable so I'll just proceed with the
> configurability of it. But note that it seems we're both in agreement
> that right now what you described requires more work before in any way
> shape or form folks start using it for the exact purpose you described.
> I
Andi, some reference to some of your old module namespace work below for
a different use case.
On Wed, Nov 05, 2014 at 10:17:38PM +0100, Johannes Berg wrote:
> On Wed, 2014-11-05 at 20:42 +0100, Luis R. Rodriguez wrote:
>
> > > No, I mean if bp_prefix were to contain some special character like
On Wed, 2014-11-05 at 20:42 +0100, Luis R. Rodriguez wrote:
> > No, I mean if bp_prefix were to contain some special character like [.
> > This can't actually happen though.
>
> OK if that can't happen then I don't see the point.
Where by "can't happen" I mean that Kconfig probably wouldn't be
On Wed, Nov 05, 2014 at 10:22:44AM +0100, Johannes Berg wrote:
> On Wed, 2014-11-05 at 10:16 +0100, Luis R. Rodriguez wrote:
>
> > > IMHO this would be better handled in the code that uses the return value
> > > to add things to the Kconfig dependencies, there you could just go
> > > if
On Wed, 2014-11-05 at 10:16 +0100, Luis R. Rodriguez wrote:
> > IMHO this would be better handled in the code that uses the return value
> > to add things to the Kconfig dependencies, there you could just go
> > if integrate:
> > deplist[sym] = ["BACKPORT_" + x for x in new]
> > else:
> >
On Wed, Nov 05, 2014 at 08:46:36AM +0100, Johannes Berg wrote:
> On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
>
> > @@ -71,6 +71,9 @@ def read_dependencies(depfilename):
> > ret[sym].append(kconfig_exp)
> > else:
> > sym, dep = item.split()
>
On Wed, Nov 05, 2014 at 08:46:36AM +0100, Johannes Berg wrote:
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
@@ -71,6 +71,9 @@ def read_dependencies(depfilename):
ret[sym].append(kconfig_exp)
else:
sym, dep = item.split()
+
On Wed, 2014-11-05 at 10:16 +0100, Luis R. Rodriguez wrote:
IMHO this would be better handled in the code that uses the return value
to add things to the Kconfig dependencies, there you could just go
if integrate:
deplist[sym] = [BACKPORT_ + x for x in new]
else:
On Wed, Nov 05, 2014 at 10:22:44AM +0100, Johannes Berg wrote:
On Wed, 2014-11-05 at 10:16 +0100, Luis R. Rodriguez wrote:
IMHO this would be better handled in the code that uses the return value
to add things to the Kconfig dependencies, there you could just go
if integrate:
On Wed, 2014-11-05 at 20:42 +0100, Luis R. Rodriguez wrote:
No, I mean if bp_prefix were to contain some special character like [.
This can't actually happen though.
OK if that can't happen then I don't see the point.
Where by can't happen I mean that Kconfig probably wouldn't be happy
Andi, some reference to some of your old module namespace work below for
a different use case.
On Wed, Nov 05, 2014 at 10:17:38PM +0100, Johannes Berg wrote:
On Wed, 2014-11-05 at 20:42 +0100, Luis R. Rodriguez wrote:
No, I mean if bp_prefix were to contain some special character like [.
You know, this use case seems unavoidable so I'll just proceed with the
configurability of it. But note that it seems we're both in agreement
that right now what you described requires more work before in any way
shape or form folks start using it for the exact purpose you described.
I also
On Wed, Nov 5, 2014 at 3:09 PM, Andi Kleen a...@firstfloor.org wrote:
You know, this use case seems unavoidable so I'll just proceed with the
configurability of it. But note that it seems we're both in agreement
that right now what you described requires more work before in any way
shape or
The only thing that was not clear to me from reviewing the module
namespace stuff a while ago was the original intent, but I confess I
actually only looked at the technical details to see if it was
applicable to the backports case, do you recall the original
motivation ?
The original intent
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> @@ -71,6 +71,9 @@ def read_dependencies(depfilename):
> ret[sym].append(kconfig_exp)
> else:
> sym, dep = item.split()
> +if bp_prefix != 'CPTCFG_':
> +dep_prefix =
From: "Luis R. Rodriguez"
The way we backport when packaging is to minimize the amount of
changes required by taking advantage of the fact that Kconfig
will treat can read CONFIG_ an environment variable with getenv()
when parsing menu entries. When doing integration we don't want
to do this so
From: Luis R. Rodriguez mcg...@suse.com
The way we backport when packaging is to minimize the amount of
changes required by taking advantage of the fact that Kconfig
will treat can read CONFIG_ an environment variable with getenv()
when parsing menu entries. When doing integration we don't want
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
@@ -71,6 +71,9 @@ def read_dependencies(depfilename):
ret[sym].append(kconfig_exp)
else:
sym, dep = item.split()
+if bp_prefix != 'CPTCFG_':
+dep_prefix =
20 matches
Mail list logo
