From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D235C53210 for ; Wed, 4 Jan 2023 20:56:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234818AbjADU4s (ORCPT ); Wed, 4 Jan 2023 15:56:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230233AbjADU4p (ORCPT ); Wed, 4 Jan 2023 15:56:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0582644F for ; Wed, 4 Jan 2023 12:56:44 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1C0D461820 for ; Wed, 4 Jan 2023 20:56:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56146C433D2; Wed, 4 Jan 2023 20:56:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672865803; bh=kjiExM4xf3HO6ijvfx7QZuh23bpGDHwsVCfc7Yyk1HU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MisCrzJOQ2AlaoDlUpXq+Z+JR+Yv85yfsw+BX1dGsdcAAK1F3KFqWAGBoy9b3AdJy tenpgFDWp1PWRHP9fBbvk/B+CgcN2tuwAvWoYjbo2ClvYi/WS8bOiPTiM8SD+w0ioz Nc/gSsFOGGJzPNfQMUb4ccqQ+d/WbQNyhHxyWiXacohkg1fgLSOTNA9MCPuXUpjBF+ zuoGh3PmfWhKbG4TMGOQvapiZ5l0VZY/jJ9gVeL7M+Vzluo0MHBzyVrwRfTqcoD/TH vi9KS8VYG7DIDxSyRvrvjduugQVqVVyyZqQTV6w+qL0+xnwnjn9Q3A8dViQx0SYWl2 WSruTixfjYQtw== Received: by pali.im (Postfix) id 6CCE2A3A; Wed, 4 Jan 2023 21:56:40 +0100 (CET) Date: Wed, 4 Jan 2023 21:56:40 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Linus Torvalds Cc: Linux Kernel Mailing List Subject: Re: Linux 6.2-rc1 Message-ID: <20230104205640.o2uy2jk4v6yfm4w3@pali> References: <20230104190115.ceglfefco475ev6c@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 04 January 2023 11:25:41 Linus Torvalds wrote: > On Wed, Jan 4, 2023 at 11:01 AM Pali Rohár 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).