On 12.07.19 01:27, Brendan Higgins wrote:
> Enrico, want me to CC you on that> and we can continue this discussion there?
Yes. But I'd prefer having an own list for it - better for sorting and
archiving ;-)
> I wonder if that would work for the testing scenario? I don't think it> is
> unreasonab
On Wed, Jul 3, 2019 at 3:42 PM Luis Chamberlain wrote:
>
> On Wed, Jul 03, 2019 at 09:31:33PM +0200, Enrico Weigelt, metux IT consult
> wrote:
> > On 03.07.19 19:35, Luis Chamberlain wrote:
> >
> > Hi,
> >
> > >> Okay, but IIRC this will add more boilerplate those modules.
> > >
> > > Just one mo
On Thu, Jul 11, 2019 at 04:07:27PM -0700, Brendan Higgins wrote:
> On Wed, Jul 3, 2019 at 3:25 PM Luis Chamberlain wrote:
> >
> > On Wed, Jul 03, 2019 at 08:57:58PM +0200, Greg Kroah-Hartman wrote:
> >
> > But again, this is a separate problem. The one I am addressing, on
> > behalf of Cristina, i
On Wed, Jul 3, 2019 at 3:25 PM Luis Chamberlain wrote:
>
> On Wed, Jul 03, 2019 at 08:57:58PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 03, 2019 at 04:50:20PM +, Luis Chamberlain wrote:
> > > On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, Jul 02, 201
On Wed, Jul 03, 2019 at 09:31:33PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 03.07.19 19:35, Luis Chamberlain wrote:
>
> Hi,
>
> >> Okay, but IIRC this will add more boilerplate those modules.
> >
> > Just one module attribute.
>
> Yes, but still one per module. This raises the quest
On Wed, Jul 03, 2019 at 08:57:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 03, 2019 at 04:50:20PM +, Luis Chamberlain wrote:
> > On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Jul 02, 2019 at 08:51:06PM +, Luis Chamberlain wrote:
> > > > On Sat, Jun
On 03.07.19 19:35, Luis Chamberlain wrote:
Hi,
>> Okay, but IIRC this will add more boilerplate those modules.
>
> Just one module attribute.
Yes, but still one per module. This raises the question whether
maintainers are willing to cope w/ tons of tiny patches for just
one line - for something
On Wed, Jul 03, 2019 at 04:50:20PM +, Luis Chamberlain wrote:
> On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jul 02, 2019 at 08:51:06PM +, Luis Chamberlain wrote:
> > > On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Jun
On Wed, Jul 03, 2019 at 02:16:44PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 28.06.19 20:40, Luis Chamberlain wrote:
>
> Hi folks,
>
> > The solution puts forward a mechanism to add a kconfig_symb where
> > we are 100% certain we have a direct module --> config mapping.
> Okay, but IIR
On Wed, Jul 03, 2019 at 09:40:48AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 02, 2019 at 08:51:06PM +, Luis Chamberlain wrote:
> > On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> > > > On Wed, Jun
On 28.06.19 20:40, Luis Chamberlain wrote:
Hi folks,
> The solution puts forward a mechanism to add a kconfig_symb where we> are
> 100% certain we have a direct module --> config mapping.
Okay, but IIRC this will add more boilerplate those modules.
And I wonder whether target binaries are the r
On Tue, Jul 02, 2019 at 08:51:06PM +, Luis Chamberlain wrote:
> On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> > > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig wrote:
> > > >
> > > > On Wed, Jun 2
On Sat, Jun 29, 2019 at 10:42:57AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> > On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig wrote:
> > >
> > > On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> > > > On Tue, Feb 5,
On Fri, Jun 28, 2019 at 11:40:22AM -0700, Luis Chamberlain wrote:
> On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> > > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain wrote:
> > > > In lieu of no Luke Skywalker,
On Wed, Jun 26, 2019 at 9:51 PM Christoph Hellwig wrote:
>
> On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> > On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain wrote:
> > > In lieu of no Luke Skywalker, if you will, for a large kconfig revamp
> > > on this, I'm inclined to beli
On Wed, Jun 26, 2019 at 03:21:08PM -0700, Luis Chamberlain wrote:
> On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain wrote:
> > In lieu of no Luke Skywalker, if you will, for a large kconfig revamp
> > on this, I'm inclined to believe *at least* having some kconfig_symb
> > exposed for some modules
On Tue, Feb 5, 2019 at 2:07 PM Luis Chamberlain wrote:
> In lieu of no Luke Skywalker, if you will, for a large kconfig revamp
> on this, I'm inclined to believe *at least* having some kconfig_symb
> exposed for some modules is better than nothing. Christoph are you
> totally opposed to this effor
On Thu, Aug 25, 2016 at 2:19 PM Luis R. Rodriguez wrote:
>
> On Thu, Aug 25, 2016 at 09:43:13AM +0200, Christoph Hellwig wrote:
> > The idea seems useful, but I reallt don't like the 'reverse-engineering'
> > approach.
> >
> > If we want to this properly from the ground up we should just split out
On Thu, Aug 25, 2016 at 09:43:13AM +0200, Christoph Hellwig wrote:
> The idea seems useful, but I reallt don't like the 'reverse-engineering'
> approach.
>
> If we want to this properly from the ground up we should just split out
> our CONFIG_ SYMBOLS into
>
> MODULE_* - builds exactly one module
On Thu, Aug 25, 2016 at 10:00:20AM +0200, Johannes Berg wrote:
>
> > The other nice thing is that we could probably fold most of the
> > Makefiles into Kconfig using that methods as well, by listing the
> > objectes required for a module, e.g.
> >
> > module NVME_TARGET
> > tristate "NVMe Tar
On 2016-08-25 09:43, Christoph Hellwig wrote:
> The idea seems useful, but I reallt don't like the 'reverse-engineering'
> approach.
>
> If we want to this properly from the ground up we should just split out
> our CONFIG_ SYMBOLS into
>
> MODULE_* - builds exactly one module (tristate, or maybe
> The other nice thing is that we could probably fold most of the
> Makefiles into Kconfig using that methods as well, by listing the
> objectes required for a module, e.g.
>
> module NVME_TARGET
> tristate "NVMe Target support"
> depends on BLOCK
> depends on CONFIGFS_FS
>
The idea seems useful, but I reallt don't like the 'reverse-engineering'
approach.
If we want to this properly from the ground up we should just split out
our CONFIG_ SYMBOLS into
MODULE_* - builds exactly one module (tristate, or maybe also as a built-in
only one, then like a bool)
CONFIG_* - j
unsubscribe backports
On 8/24/16, Luis R. Rodriguez wrote:
> On Wed, Aug 24, 2016 at 01:05:04PM +0200, Michal Marek wrote:
>> On 2016-08-23 23:32, Luis R. Rodriguez wrote:
>> > On Fri, Aug 19, 2016 at 11:07:36AM +0200, Michal Marek wrote:
>> >> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
>> >>>
On Wed, Aug 24, 2016 at 01:05:04PM +0200, Michal Marek wrote:
> On 2016-08-23 23:32, Luis R. Rodriguez wrote:
> > On Fri, Aug 19, 2016 at 11:07:36AM +0200, Michal Marek wrote:
> >> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
> >>> On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
>
On 2016-08-23 23:32, Luis R. Rodriguez wrote:
> On Fri, Aug 19, 2016 at 11:07:36AM +0200, Michal Marek wrote:
>> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
>>> On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
>>>
This patchset implements dynamic pegging of kconfig symbol
>>>
On Fri, Aug 19, 2016 at 11:07:36AM +0200, Michal Marek wrote:
> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
> > On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
> >
> >> This patchset implements dynamic pegging of kconfig symbol
> >> into driver modinfo section
> >
> > First a l
On Mon, Aug 22, 2016 at 09:35:47PM +0200, Cristina-Gabriela Moraru wrote:
> 2016-08-18 19:55 GMT+02:00 Luis R. Rodriguez :
> > On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
> >
> >> This patchset implements dynamic pegging of kconfig symbol
> >> into driver modinfo section
> >
>
2016-08-19 11:07 GMT+02:00 Michal Marek :
> On 2016-08-18 19:55, Luis R. Rodriguez wrote:
>> On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
>>
>>> This patchset implements dynamic pegging of kconfig symbol
>>> into driver modinfo section
>>
>> First a little bit of motivation here
2016-08-18 19:55 GMT+02:00 Luis R. Rodriguez :
> On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
>
>> This patchset implements dynamic pegging of kconfig symbol
>> into driver modinfo section
>
> First a little bit of motivation here helps, so let me try to
> help fill in some gaps
On 2016-08-18 19:55, Luis R. Rodriguez wrote:
> On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
>
>> This patchset implements dynamic pegging of kconfig symbol
>> into driver modinfo section
>
> First a little bit of motivation here helps, so let me try to
> help fill in some gap
On Wed, Aug 17, 2016 at 09:26:58PM +0200, Cristina Moraru wrote:
> This patchset implements dynamic pegging of kconfig symbol
> into driver modinfo section
First a little bit of motivation here helps, so let me try to
help fill in some gaps. This may help explain what you have
been working on a b
This patchset implements dynamic pegging of kconfig symbol
into driver modinfo section
* updates streamline_config.pl to generate the auxiliary file
scripts/mod/Module.ksymb containing associations of driver file
names and corresponding kconfig symbols CONFIG_*
* updates Makefiles to trigger strea
33 matches
Mail list logo