From: "Pali Rohár" <pali@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 6.2-rc1
Date: Wed, 4 Jan 2023 22:27:29 +0100 [thread overview]
Message-ID: <20230104212729.s6mdthwqdoxzbjga@pali> (raw)
In-Reply-To: <20230104205640.o2uy2jk4v6yfm4w3@pali>
On Wednesday 04 January 2023 21:56:40 Pali Rohár wrote:
> On Wednesday 04 January 2023 11:25:41 Linus Torvalds wrote:
> > On Wed, Jan 4, 2023 at 11:01 AM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > Driver is still used and userspace tools for it are part of the udftools
> > > project, which is still under active maintenance. More people already
> > > informed me about this "surprise".
> >
> > Why is that driver used?
> >
> > It's *literally* pointless. It's just a shell that forwards ioctl's to
> > the real drivers.
> >
> > > Any comments on this? Because until now nobody answered why this
> > > actively used driver was removed from kernel without informing anybody:
> >
> > Well, it's been marked as deprecated for five years, so any kernel
> > config should have gotten this notice for the help entry
> >
> > Note: This driver is deprecated and will be removed from the
> > kernel in the near future!
> >
> > but I guess people didn't notice.
> >
> > It could be re-instated, but it really is a completely useless driver.
> > Just use the *regular* device nodes, not the pointless pktcd ones.
> >
> > Is there any real reason why udftools can't just use the normal device node?
> >
> > The historical reason for this driver being pointless goes back *much*
> > longer than five years - it used to be that the pktcd driver was
> > special, and was the only thing that did raw commands.
> >
> > But the regular block layer was taught to do that back around 2004, so
> > the "pktcd" driver has literally just been a pointless shell for
> > almost two decades.
> >
> > And I know it was in 2004, because I actually did most of that "make
> > SCSI commands generic" work myself (but had to go back to the old BK
> > archives to find the exact date - it's been two decades, after all).
> >
> > I did it because I was fed up with the crazy pktcd driver requiring
> > extra work, when I just wanted to write CD's on my regular IDE CD-ROM
> > the obvious way.
> >
> > So if there is some reason to actually use the pktcd driver, please
> > tell us what that is.
> >
> > Linus
>
> Last time I did big retest of optical media was two years ago. At that
> time kernel was not able to mount CD-RW disc in full read-write mode
> from the normal node /dev/cdrom. Via pktcdvd driver mapping it was
> possible without any issue. Was there any change in last 5 (or more)
> years in this CD-RW area? Mounting CD-RW media in read-only mode via
> normal /dev/cdrom node always worked fine. Also "burning" CD-R media
> with userspace burning tools on normal /dev/cdrom node also worked.
> But here it is CD-RW media in read-write mode with kernel udf filesystem
> driver without any userspace involved (after proper formatting).
In commit where was pktcdvd dropped is written:
https://git.kernel.org/torvalds/c/f40eb99897af665f11858dd7b56edcb62c3f3c67
* At the lowest level, there is the standard driver for the CD/DVD device,
* such as drivers/scsi/sr.c. This driver can handle read and write requests,
* but it doesn't know anything about the special restrictions that apply to
* packet writing. One restriction is that write requests must be aligned to
* packet boundaries on the physical media, and the size of a write request
* must be equal to the packet size. Another restriction is that a
* GPCMD_FLUSH_CACHE command has to be issued to the drive before a read
* command, if the previous command was a write.
*
* The purpose of the packet writing driver is to hide these restrictions from
* higher layers, such as file systems, and present a block device that can be
* randomly read and written using 2kB-sized blocks.
Were all these write restrictions implemented in sr.c driver? Do you
remember other details?
Because CD-RW support into kernel was really introduced in 2004 in
this historical commit, but it was not for SCSI sr.c driver:
https://git.kernel.org/history/history/c/2f8e2dc86c9876edca632e8ef2ab1f68d1b753f0
next prev parent reply other threads:[~2023-01-04 21:29 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-25 22:07 Linux 6.2-rc1 Linus Torvalds
2022-12-26 19:52 ` Guenter Roeck
2022-12-26 20:56 ` Linus Torvalds
2022-12-26 21:03 ` Kees Cook
2022-12-26 22:10 ` Guenter Roeck
2022-12-27 0:29 ` Guenter Roeck
2022-12-27 1:32 ` Kees Cook
2022-12-27 5:52 ` Guenter Roeck
2022-12-28 3:40 ` Kees Cook
2022-12-28 14:44 ` Guenter Roeck
2023-01-07 0:06 ` Jaegeuk Kim
2022-12-26 22:41 ` Vlastimil Babka
2022-12-26 21:10 ` Max Filippov
2022-12-26 22:08 ` Guenter Roeck
2022-12-27 8:29 ` Build regressions/improvements in v6.2-rc1 Geert Uytterhoeven
2022-12-27 8:35 ` Geert Uytterhoeven
2023-01-01 1:33 ` Rob Landley
2023-01-01 12:24 ` Geert Uytterhoeven
2023-01-04 6:32 ` Michael Ellerman
2023-01-06 15:10 ` John Paul Adrian Glaubitz
2023-01-06 15:17 ` Geert Uytterhoeven
2023-01-06 15:18 ` Geert Uytterhoeven
2023-01-17 16:42 ` Calculating array sizes in C - was: " John Paul Adrian Glaubitz
2023-01-17 17:01 ` Geert Uytterhoeven
2023-01-17 17:06 ` John Paul Adrian Glaubitz
2023-01-17 20:05 ` Geert Uytterhoeven
2023-01-17 20:37 ` John Paul Adrian Glaubitz
2023-01-19 22:11 ` Michael.Karcher
2023-01-20 3:31 ` Rob Landley
2023-01-20 10:53 ` Segher Boessenkool
2023-01-20 18:29 ` Michael.Karcher
2023-01-20 8:49 ` John Paul Adrian Glaubitz
2023-01-20 19:29 ` Michael Karcher
2023-01-21 21:26 ` John Paul Adrian Glaubitz
2023-01-06 15:39 ` Alex Deucher
2023-01-04 19:01 ` Linux 6.2-rc1 Pali Rohár
2023-01-04 19:25 ` Linus Torvalds
2023-01-04 20:56 ` Pali Rohár
2023-01-04 21:27 ` Pali Rohár [this message]
2023-01-04 21:32 ` Linus Torvalds
2023-01-04 21:43 ` Jens Axboe
2023-01-05 11:25 ` Greg Kroah-Hartman
2023-01-05 15:26 ` Jens Axboe
2023-01-05 17:42 ` Pali Rohár
2023-01-05 17:45 ` Jens Axboe
2023-01-05 19:06 ` Linus Torvalds
2023-01-05 19:22 ` Pali Rohár
2023-01-05 19:40 ` Jens Axboe
2023-01-05 20:03 ` Linus Torvalds
2023-01-05 20:33 ` Jens Axboe
2023-01-06 16:58 ` Pali Rohár
2023-01-06 17:04 ` Jens Axboe
2023-01-28 19:34 ` pktcdvd Pali Rohár
2023-01-28 19:43 ` pktcdvd Linus Torvalds
2023-01-29 21:53 ` pktcdvd Jens Axboe
2023-01-29 21:55 ` pktcdvd Jens Axboe
2023-01-29 22:21 ` pktcdvd Pali Rohár
2023-01-29 22:34 ` pktcdvd Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230104212729.s6mdthwqdoxzbjga@pali \
--to=pali@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).