Re[2]: Kernel bug tracker

2021-09-06 Thread Adverg Ebashinskii

 
> Ok. Here is the simple one. The other comes in a separate mail.
 
Hello Thomas,
 
I will try to submit the simplest one first (my very first patch). There are to 
questions: 1. When submitting the patch should I include you in the copy as the 
original author? 2. Can I also co-sign the patch by myself?
 
--
Regards,
Adverg Ebashinskii
 
 ___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re[2]: Kernel bug tracker

2021-09-05 Thread Adverg Ebashinskii

 
Hi Thomas,
 
Thanks for the brief explanation of the bugs.
 
>  i'll hand over my patch as guideline, or as 
>  base for own work, or just for review, testing, and posting
 
If you could share your patch here to understand the problem better I would 
gladly dig into it.
 
--
Regards,
Adverg Ebashinskii
 
 ___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Re[2]: Kernel bug tracker

2021-08-31 Thread Valdis Klētnieks
On Sun, 29 Aug 2021 12:39:28 +0300, Adverg Ebashinskii said:

> Hi Anatoly,

> Thank you very much for your response. https://bugzilla.kernel.org looks
> exactly what I was looking for.

Note that the Bugzilla probably *isn't* what you're looking for, if you're
looking for small easy patches to start with.

Hint: Many long-time kernel developers say the bugzilla is where kernel bugs go
to die.

That's because if it's an open bug in the bugzilla, one or more of the
following things are probably true:

* The bug has actually already been fixed but nobody ever bothered closing the
bugzilla entry.

* The bug isn't reproducible on a common configuration, either due to specific
hardware requirements (like a specific card at a specific firmware release), or
the software replicator for the issue isn't known, so only one computer can
reliably trigger the issue. (A few years back, Linus and a few others finally
swatted a bug that triggered on *one* system several times a week.  It turned
out to be a race condition, with a window caused by interrupts being re-enabled
3 instructions too early.  So that one system was doing something that hit this
literally billionth-of-a-second wide window several times a week).

* The bug doesn't have an obvious/easy fix, so it's sitting in the bugzilla
while people try to come up with a fix that isn't too ugly to be allowed to
live. Once you get all the git configuration done and working, it's usually
faster to just create and submit the patch rather than open a bugzilla entry,
so bugzilla entries don't get created for obvious patches.

* The bug report requires more information, and the original reporter of the
bug has evaporated.

Your best source for low-hanging fruit these days is probably drivers/staging,
as pretty much everything under there is *known* to be less-than-optimal. There
should even be a TODO file for each driver in there, saying what stuff is known
to need work.  (Note that it's always possible that things get fixed but the
TODO file doesn't get updated - that's a potential source of cleanup patches as
well)

Good luck.  And remember to back up your system before testing patches. :)



pgpKUuyvSyI7J.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re[2]: Kernel bug tracker

2021-08-29 Thread Adverg Ebashinskii

 
Hi Anatoly,
 
Thank you very much for your response. https://bugzilla.kernel.org looks 
exactly what I was looking for.
 
--
Regards,
Adverg Ebashinskii
 
 
 ___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies