On Thu, Oct 20, 2022, at 12:06, Thomas Schmitt wrote: > Arnd Bergmann wrote: > > > https://lore.kernel.org/linux-scsi/20201120140633.1673-1-scdbac...@gmx.net/T/ > [PATCH] isofs: fix Oops with zisofs and large PAGE_SIZE > > > https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbac...@gmx.net/T/ > [PATCH v2 0/2] Fix automatic CD tray loading for data reading via sr > [PATCH v2 1/2] cdrom: delegate automatic CD tray loading to callers of > cdrom_open() > [PATCH v2 2/2] sr: fix automatic tray loading for data reading > > I made more bug fixes and a wishlist patch two years ago. > But keeping them up to date with the agile kernel development is quite a > big task for me. (As said: userlander.)
These look like you did everything right, and they should have been picked up by the scsi maintainers. If you ever re-send them, I would suggest putting the maintainers in 'To:' for the email and the mailing list in Cc, and asking them specifically to pick up the patches. > Especially fs/isofs has no maintainer, so i could only submit to linux-scsi > because of the proximity to cdrom and sr. I had hoped that above two > patches would be considered as modest self-introduction, but obviously my > social skills are not sufficient. 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 <v...@zeniv.linux.org.uk> To: Jan Kara <j...@suse.cz> To: Andrew Morton <a...@linux-foundation.org> Cc: Arnd Bergmann <a...@arndb.de> Cc: Deepa Dinamani <deepa.ker...@gmail.com> Cc: linux-fsde...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: y2...@lists.linaro.org Can you rebase the patch on top of v6.1-rc1 and send it to this list of people? I'll reply with a 'Reviewed-by' tag, and one of the above should be able to pick it up. > This is what i think needed mending in kernel 5.10 two years ago: > > [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO track > (Most drives report the 2 unreadable TAO run-out blocks as > part of the medium capacity.) > > [PATCH 0/1] sr: verify that last_written block is readable before deriving > size from it > (Size assessment of optical media in Linux is quite a mess > and can overshoot beyond the TAO run-out problem.) > > [PATCH 0/4] Attribute size 0 to sr device if no readable medium is loaded > (Linux reports the size of the last loaded medium, or 2048 > bytes if a blank medium is inserted.) > > [PATCH 0/4] Make mount -t iso9660 -o session=N work on DVD and BD media up > to N=168 > (While -o sbsector= works for all media types, session= works > only with CD media.) > > [PATCH 0/1] isofs: truncate oversized Rock Ridge names to 255 bytes > (Truncation currently happens if name length is >= 254 and > then cuts off much more of the name than needed.) > > When those bugs would be fixed (or mitigated in case of TAO), i hoped to > get a favor for my own hobby: > > [PATCH 0/3] Introduce a new ioctl CDROM_SIMUL_CHANGE for burn programs > (Currently Linux knows about new content created via ioctl > SG_IO only after eject and reload of the Medium.) > > The housekeeping aspects of kernel development are really hard for me to > master. I don't strive to become a regular contributor. But seeing those > bugs since years causes me to mention them when there is hope to meet > kernel developers. > > So: > Thanks a lot for replying. Is there a chance to get you interested in the > other bugs above and maybe even my wish for ioctl CDROM_SIMUL_CHANGE ? I mainly care about the y2038 issue here, haven't done anything interesting on cdrom drivers in 20 years ;-) Arnd
