All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Mischa Baars <mjbaars1977.linux-block@cyberfiber.eu>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: packet writing support
Date: Mon, 7 Oct 2019 10:45:00 +0200	[thread overview]
Message-ID: <ce56abfd-f309-5471-0201-6226731fa452@suse.de> (raw)
In-Reply-To: <977cedab873dfe0705701b3b43c621a7a516e396.camel@cyberfiber.eu>

On 10/7/19 10:07 AM, Mischa Baars wrote:
> On Mon, 2019-10-07 at 09:23 +0200, Hannes Reinecke wrote:
>> On 10/7/19 9:02 AM, Mischa Baars wrote:
>>> On Sun, 2019-10-06 at 09:10 -0600, Jens Axboe wrote:
>> [ .. ]
>>>> I'm saying that you are comparing apples to oranges. The floppy driver
>>>> might be older tech, but it's much more used than pktcdvd. It's not the
>>>> case that we must pick one over the other, in terms of what stays and
>>>> what goes.
>>>>
>>>
>>> Yes we are, sort of. You can even have my pear. That's exactly the problem with your story :)
>>>
>>> A DVD is 4Gb and Blueray goes all the way up to 100Gb, while a floppy disc is 1.44Mb.
>>> Who would want to write his backup files to 1.44Mb floppy disc these days?
>>>
>> Why do you keep on bringing up floppy?
>> I was under the impression that you wanted to use pktdvd, not floppy...
>> And as Jens made it clear, any potential removal of the floppy driver
>> will have _zero_ influence on the future of pktdvd.
> 
> I do not keep bringing up the floppy drives. I'm merely trying to point
> out that removing the floppy driver is the more logical course of action.
>
??

> Also, you must be mistaken. It's not about the potential removal of the
> floppy driver, it's about the removal of the packet writing driver. There
> will be no pktcdvd kernel module in the future. To be precise, both reading
> and writing dvd's is already unsupported in the latest linux-next kernel.
>
I know what pktcddvd is, and I know what it's used for.
All what Jens has been complaining is that the code has been
unmaintained for quite a while, and only very few bugfixes coming in.
Which typically indicates that there are only very few users left, if any.

>> And in either case, the main question here was:
>> Will you rebase your project to latest mainline once it's ready?
>> Or will you settle on a kernel version to do your development on, and
>> continue using that for your project?
> 
> No, the code is intended for companies like AMD, Intel or ARM. It
> is not indended for the opensource community. Does that mean that
> I cannot develop on an opensource platform? Is that you are trying to tell me?
> 
No.
What we are trying to tell you is that:
a) The code is unmaintained, and (as of now) there hadn't been anyone
expressing an interest. If you require this driver for your project,
send a mail to Jens Axboe that you are willing to take over
maintainership for this driver. Then you get to decide if and when the
driver should be obsoleted. You'll be responsible for fixing issues with
that driver, true, but to quote the brexit axiom: you can't have the
cake and eat it ...
b) The underlying hardware is becoming obsolete. SCSI CD-ROM drivers are
a thing of the past, and ATAPI hardware is on its way to be replaced
with USB Flash. Case in point: ATAPI support got dropped from the ATA
spec ACS-4, and most laptops nowadays don't even have a DVD slot
anymore. Hence I would question the need for DVD support in the future.
Unless, of course, you do happen to work for a company producing said
devices, in which case I would strongly recommend going for a) above.

>> Incidentally: I _do_ know of one company who happily will provide you
>> with a stable OS to base your development on ... three, actually ...
> 
> You would like me to work with Microsoft products, don't you?
> 
Look at my signature. No.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      Teamlead Storage & Networking
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 247165 (AG München), GF: Felix Imendörffer

  reply	other threads:[~2019-10-07  8:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-05 10:12 packet writing support Mischa Baars
2019-10-05 15:50 ` Jens Axboe
2019-10-06  7:31   ` Mischa Baars
2019-10-06 15:10     ` Jens Axboe
2019-10-07  7:02       ` Mischa Baars
2019-10-07  7:23         ` Hannes Reinecke
2019-10-07  8:07           ` Mischa Baars
2019-10-07  8:45             ` Hannes Reinecke [this message]
2019-10-07  9:11               ` Mischa Baars
2019-10-07  9:17                 ` Mischa Baars
2019-10-07 14:22                   ` Bart Van Assche
2019-10-07 14:36                     ` Mischa Baars
2019-10-07 16:13                     ` Mischa Baars
2019-10-07 16:19                       ` Jens Axboe
2019-10-07 17:31                         ` Mischa Baars
2019-10-07 10:02                 ` Hannes Reinecke
2019-10-07 14:10         ` Jens Axboe
2019-10-07 14:19           ` Mischa Baars
2019-10-06  8:31   ` Mischa Baars
2019-10-06 20:48     ` Laurence Oberman
2019-10-07  8:10       ` Mischa Baars
2019-10-07  9:02       ` Mischa Baars
  -- strict thread matches above, loose matches on Subject: below --
2019-10-04  9:22 Mischa Baars
2019-10-04  9:21 Mischa Baars

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=ce56abfd-f309-5471-0201-6226731fa452@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=mjbaars1977.linux-block@cyberfiber.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.