On 12/29/12 1:12 PM, Greg Troxel wrote:
I would like to have a way to pass a string composed of the same flags
(we can continue to use our existing "-a", "-s" and other flags) in a
consistent manner from one platform to another, to be able to adjust
driver options, kernel options, wha
I would like to have a way to pass a string composed of the same flags
(we can continue to use our existing "-a", "-s" and other flags) in a
consistent manner from one platform to another, to be able to adjust
driver options, kernel options, whatever, and to be able to expect it
to be si
I'm only just starting to think of this as a possible reality, but I'd
like to establish a (better) MI way of passing args to the kernel. In
my particular case, I'm interested in passing the root device to the
kernel from u-boot on several evbarm and evbppc platforms; I can easily
see wanting
On Sat, Dec 29, 2012 at 03:03:07PM +0100, Marc Balmer wrote:
> Yes absolutely. As long as we talk "modules-only", there is no problem.
But, then, for the time being, wouldn't this provide a simple compromise?
As you noted previously, lua(4) is experimental, so I see no reason why it
couldn't be
On Sat, 29 Dec 2012, Marc Balmer wrote:
Am 29.12.2012 um 14:57 schrieb Paul Goyette :
On Sat, 29 Dec 2012, Marc Balmer wrote:
this is going to upset dyoung i'm sure :) but it seems to me that
if these invasive changes to individual subsystems are needed like
this, and we want them to be opti
Am 29.12.2012 um 14:57 schrieb Paul Goyette :
> On Sat, 29 Dec 2012, Marc Balmer wrote:
>
>>> this is going to upset dyoung i'm sure :) but it seems to me that
>>> if these invasive changes to individual subsystems are needed like
>>> this, and we want them to be optional, then imo they should b
On Sat, 29 Dec 2012, Marc Balmer wrote:
this is going to upset dyoung i'm sure :) but it seems to me that
if these invasive changes to individual subsystems are needed like
this, and we want them to be optional, then imo they should be on
a per-subsystem basis, not global. eg something like:
> > is there a way to structure the code such that there
> > are more modules (whether modloaded or statically
> > linked) such that:
> >
> > gpiosim_lua: gpiosim lua
>
> Did you mean having two gpiosim modules, one with and one without Lua?
no.
i mean having a gpiosim_lua module that adds l
Am 29.12.2012 um 12:47 schrieb matthew green :
>
>> Which is fine for gpiosim, as it can just depend on the lua
>> module. For LINEDISC_LUA, there would have to be some kind of hook to
>> which the lua module would attach when loaded, so that the kernel would
>> still function even without
> Which is fine for gpiosim, as it can just depend on the lua
> module. For LINEDISC_LUA, there would have to be some kind of hook to
> which the lua module would attach when loaded, so that the kernel would
> still function even without the module loaded.
since this means i can't use gpios
On May 21, 6:10am, Marc Balmer wrote:
}
} > this is going to upset dyoung i'm sure :) but it seems to me that
} > if these invasive changes to individual subsystems are needed like
} > this, and we want them to be optional, then imo they should be on
} > a per-subsystem basis, not global. eg some
> this is going to upset dyoung i'm sure :) but it seems to me that
> if these invasive changes to individual subsystems are needed like
> this, and we want them to be optional, then imo they should be on
> a per-subsystem basis, not global. eg something like:
>
> options LINEDISC_LUA
>
12 matches
Mail list logo
