On Wed, Jul 3, 2013 at 2:31 PM, Lucas De Marchi
wrote:
> On Wed, Jul 3, 2013 at 6:23 PM, Michal Marek wrote:
>> Dne 3.7.2013 23:17, Andy Lutomirski napsal(a):
>>> On Wed, Jul 3, 2013 at 2:03 PM, Michal Marek wrote:
Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
> One caveat. Sometimes
Michal, All,
On 2013-07-03 23:23 +0200, Michal Marek spake thusly:
> Dne 3.7.2013 23:17, Andy Lutomirski napsal(a):
> > On Wed, Jul 3, 2013 at 2:03 PM, Michal Marek wrote:
> >> Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
> >>> One caveat. Sometimes we have manufactured parameters intentionall
On Wed, Jul 3, 2013 at 6:23 PM, Michal Marek wrote:
> Dne 3.7.2013 23:17, Andy Lutomirski napsal(a):
>> On Wed, Jul 3, 2013 at 2:03 PM, Michal Marek wrote:
>>> Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
One caveat. Sometimes we have manufactured parameters intentionally
to cause a
Dne 3.7.2013 23:17, Andy Lutomirski napsal(a):
> On Wed, Jul 3, 2013 at 2:03 PM, Michal Marek wrote:
>> Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
>>> One caveat. Sometimes we have manufactured parameters intentionally
>>> to cause a module to fail. We should standardize that piece.
>>
>> You
On Wed, Jul 3, 2013 at 2:03 PM, Michal Marek wrote:
> Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
>> One caveat. Sometimes we have manufactured parameters intentionally
>> to cause a module to fail. We should standardize that piece.
>
> You have:
>
> blacklist foo
>
> to prevent udev from lo
Dne 1.7.2013 18:33, Jonathan Masters napsal(a):
> One caveat. Sometimes we have manufactured parameters intentionally
> to cause a module to fail. We should standardize that piece.
You have:
blacklist foo
to prevent udev from loading a module and
install foo /bin/true
to prevent modprobe f
Jonathan Masters writes:
> One caveat. Sometimes we have manufactured parameters intentionally to cause
> a module to fail. We should standardize that piece.
Certainly. Can you give an example?
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
One caveat. Sometimes we have manufactured parameters intentionally to cause a
module to fail. We should standardize that piece.
--
Sent from my iPad
On Jul 1, 2013, at 4:53, Rusty Russell wrote:
> Rusty Russell writes:
>> Lucas De Marchi writes:
>>> Hi Rusty,
>>>
>>> On Mon, Mar 18, 2013
Rusty Russell writes:
> Lucas De Marchi writes:
>> Hi Rusty,
>>
>> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell
>> wrote:
>>> Andy Lutomirski writes:
On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
wrote:
> Andy Lutomirski writes:
>> On Thu, Mar 14, 2013 at 10:03 PM, Rus
Lucas De Marchi writes:
> Hi Rusty,
>
> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
>>> wrote:
Andy Lutomirski writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
> wrote:
>> Err,
Ben Hutchings writes:
> This should also go to stable, so the downgrading issue doesn't continue
> to bite people.
Andy was complaining about experimental params going away: I haven't
heard a single complaint about the downgrading issue. I think it's a
nice to have, which is why I mentioned it.
On Tue, Mar 19, 2013 at 8:32 PM, Andy Lutomirski wrote:
> On Tue, Mar 19, 2013 at 8:26 PM, Lucas De Marchi
> wrote:
>> Hi Rusty,
>>
>> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell
>> wrote:
>>> Andy Lutomirski writes:
On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
wrote:
> A
On Tue, Mar 19, 2013 at 8:26 PM, Lucas De Marchi
wrote:
> Hi Rusty,
>
> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
>>> wrote:
Andy Lutomirski writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Ru
Hi Rusty,
On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell wrote:
> Andy Lutomirski writes:
>> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell wrote:
>>> Andy Lutomirski writes:
On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
wrote:
> Err, yes. Don't remove module parameters, th
On Tue, 2013-03-19 at 13:02 +1030, Rusty Russell wrote:
> Andy Lutomirski writes:
> > On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
> > wrote:
> >> Andy Lutomirski writes:
> >>> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
> >>> wrote:
> Err, yes. Don't remove module parameters, the
Andy Lutomirski writes:
> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
>>> wrote:
Err, yes. Don't remove module parameters, they're part of the API. Do
you have a particular example?
>>>
>>> So
On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell wrote:
> Andy Lutomirski writes:
>> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
>> wrote:
>>> Andy Lutomirski writes:
Current parameter behavior is odd. Boot parameters that have values
and don't match anything become environment va
Andy Lutomirski writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> Current parameter behavior is odd. Boot parameters that have values
>>> and don't match anything become environment variables, with no
>>> warning. Boot parameters without values tha
On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell wrote:
> Andy Lutomirski writes:
>> Current parameter behavior is odd. Boot parameters that have values
>> and don't match anything become environment variables, with no
>> warning. Boot parameters without values that don't match anything
>> go in
Andy Lutomirski writes:
> Current parameter behavior is odd. Boot parameters that have values
> and don't match anything become environment variables, with no
> warning. Boot parameters without values that don't match anything
> go into argv_init. Everything goes into /proc/cmdline.
>
> The ini
Current parameter behavior is odd. Boot parameters that have values
and don't match anything become environment variables, with no
warning. Boot parameters without values that don't match anything
go into argv_init. Everything goes into /proc/cmdline.
The init_module and finit_module syscalls,
21 matches
Mail list logo
