On Thu, Oct 20, 2022, at 16:45, Thomas Schmitt wrote: >> I think the hard part here is knowing who to send the patches to. >> Unmaintained file systems are particularly tricky, in this case I >> would have used >> >> To: Alexander Viro <[email protected]> >> To: Jan Kara <[email protected]> >> To: Andrew Morton <[email protected]> >> Cc: Arnd Bergmann <[email protected]> >> Cc: Deepa Dinamani <[email protected]> >> Cc: [email protected] >> Cc: [email protected] >> Cc: [email protected] > > Well, that's quite disjoint from the list which i figured out: > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] >
This would be the correct list for the cdrom driver patches, my list above would be for the isofs time64 patch. >> Can you rebase the patch on top of v6.1-rc1 and send it to >> this list of people? > > I know the word "rebase" but cannot promise that i can fill it with > substance soon ... > > What kernel branches should i choose for sr and for isofs ? It's generally ok to just use the latest -rc1 (right now 6.1-rc1) as the base, unless a maintainer asks you to use their tree as a base. >> I mainly care about the y2038 issue here, > > If you want to do us both a favor then bring the changes from > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627#38 > into the kernel. > Feel free to take my reasoning and demonstration text. The code change is > trivial. Done now. I've left you as author and first Signed-off-by though. While the change itself is trivial, the important bit is identifying the problem, and you did that. > It might be worth to verify my claims: > > The only callers of iso_date() are in isofs/inode.c and isofs/rock.c > and put the result into struct inode.i_{a,c,m}time.tv_sec which is > of type time64_t. > The time value of iso_date() essentially stems from mktime64(). > > and to exercise the demonstration by a xorriso-made ISO. I could immediately tell that your patch is correct when I saw it. Arnd
