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
20 matches
Mail list logo
