linux-kernel - Re: Contribution to Linux Kernel.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Sep 2017 16:03:14 -0300
From:   Javier Romero <linux.kernel.programming@...il.com>
To:     Ken Moffat <zarniwhoop@...world.com>, linux-kernel@...r.kernel.org
Subject: Re: Contribution to Linux Kernel.

Hi,

Last question, it will be the same to do Kernel testing on a virtual 
machine, or it will be better to do kernel testing over a no virtual 
machine?

Regards,



Javi


El 24/09/17 a las 17:25, Ken Moffat escribió:
> On Sun, Sep 24, 2017 at 12:52:08PM -0300, Javier Romero wrote:
>> Hi Ken,
>>
>> Thank you for your answer.
>>
>> Will it be better to work with linux-next Kernel for testing?
>>
>> Regards.
>>
> Yes, no, maybe.  I can't say what will work (process) for you, it
> depends in part on what you want to test, and how flakey that is at
> any particular time.
>
> The -next kernels are transient - what is there today might be
> removed tomorrow, what is in linus's -rc kernels (and in point
> releases of stable kernels) usually remains unless somebody finds a
> showstopper bug.
>
> If you are testing -next, expect to find more problems : in theory
> everything which gets to Linus's tree has been through an amount of
> testing before he applies it.
>
> Most people have limited time to test kernels.  Build farms usually
> run boot tests on all of these kernels, but do very little testing
> of whether or not any particular use is worse than before.
>
> For any of these, expect problems to arise when least convenient to
> you.  I try to test linus's -rc kernels on my own hardware,
> typically not until at least -rc2, and then once or twice after
> that.
>
> On occasion I test patchsets which look interesting, usually I end
> up wishing I had not bothered (they claim to help things, but do
> little or nothing for my machines).
>
> The other problem with testing, when you do find a real issue, is
> making sure it is repeatable so that you can bisect reliably.
>
> In short, test what interests you.  It's like writing or fixing
> code for the kernel as a hobby - work on what matters to you.
> Getting enough experience and visibility to become paid to code is a
> different thing entirely, I can't advise on that.
>
> So, for me it is just a hobby (with a side order of "hope this new
> release doesn't break anything for me").
>
> If you are not being paid for it, try to enjoy it.
>
> ĸen