On Thu, 27 Aug 2020, Thomas Schmitt wrote: > Hi, > > Lukas Bulwahn wrote: > > Just take all maintainers as recipients. > > axboe@xxxxxxxxx linux-kernel@xxxxxxxxxxxxxxx jejb@xxxxxxxxxxxxx > > martin.petersen@xxxxxxxxxx linux-scsi@xxxxxxxxxxxxxxx > > Really that loudly ? > Ain't linux-kernel@xxxxxxxxxxxxxxx too general ? > > Don't worry about CCing linux-kernel, at this point, it is more for the purpose of a "pretty complete" email archive. Nobody follows it at full length, some just have some smart scripts to react to senders, keywords, files, etc. > > It is probably best to base it on v5.9-rc2 > > Done. The patch was accepted by git apply. git diff looks good. > (There were indeed changes in cdrom.c and cdrom.h. It's not that dead. :)) > > It compiles, but does not boot: > > [1.099627] nvme nvme0: failed to set APST feature (-10) > Gave up waiting for root filesystem device > > I booted the 5.8 kernel and was happy to see my SSD well and alive. > Then i reverted my changes, compiled and installed the original 5.9-rc2. > Same boot failure (it would have been astonishing if not). > > So i cannot test on 5.9-rc2. > (Had to manually rename vmlinuz-5.9.0-rc2-ts and initrd.img-5.9.0-rc2-ts > before update-grub was willing to create a .cfg which does not boot it > by default. Eww ... whenever i leave the trodden path ...) > > > > check if it cleanly applies on the latest linux-next > > I read > https://www.kernel.org/doc/man-pages/linux-next.html > and did without really knowing why: > > $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > $ git fetch linux-next > ... > * [new branch] akpm -> linux-next/akpm > * [new branch] akpm-base -> linux-next/akpm-base > * [new branch] master -> linux-next/master > * [new branch] pending-fixes -> linux-next/pending-fixes > * [new branch] stable -> linux-next/stable > * [new tag] next-20200827 -> next-20200827 > $ git checkout master > ... > $ git remote update > ... > Fetching linux-next > $ git checkout -B linux-next-20200827-ts-issue-2 next-20200827 > Switched to a new branch 'linux-next-20200827-ts-issue-2' > $ git apply /home/thomas/v5.9-rc2_issue_2.git.diff > $ > > Compilation succeeds and it boots. > > dd if=/dev/sr0 bs=2048 count=1 of=/dev/null > dd if=/dev/sr1 bs=2048 count=1 of=/dev/null > both succeed starting from open tray with a readable medium in it. > > So shall i base my patch on next-20200827 ? > Yes, you can base it on next-20200827 (it probably applies on the current master as well). You can use git format-patch --base, then maintainers know where it applied cleanly. And if it does not apply on their tree, when they include, they will let you know. > ------------------------------------------------------------------------- > > > > Please also tell me if my mailer (used with this mail) would cause > > > problems. > > > I suggest [...] git send-email ... <patch> > > I am not sure whether i can get git send-email to work due to local > network issues. My free software mails go out by a primitive SMTP client > which gets fed with plain text files, usually created by vim. > > Thus i ask whether my mails show any properties which would hamper > acceptance of a patch, which i would generate by git format-patch. > > (I look at patches in https://marc.info/?l=linux-scsi and will try to > mimick them in my text file as good as possible.) > > Do not look at marc.info, it might have already messed up the email. Archives at https://lore.kernel.org/ can give you the raw text and that archive is tested among kernel maintainers for picking patches. You can prepare your patch and send it to kernelnewbies. Then, pick it from https://lore.kernel.org/kernelnewbies/ and try to apply your own patch with git am. If that works, it is probably fine. Lukas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
