All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Mischa Baars <mjbaars1977.linux-block@cyberfiber.eu>,
	linux-block@vger.kernel.org
Subject: Re: packet writing support
Date: Sun, 6 Oct 2019 09:10:44 -0600	[thread overview]
Message-ID: <fc70b63f-3780-5654-6bc5-0f2d6115bff0@kernel.dk> (raw)
In-Reply-To: <a4b89c40caf62166ab7078296d73b6ae0f35adaf.camel@cyberfiber.eu>

On 10/6/19 1:31 AM, Mischa Baars wrote:
> Hi Jens,
> 
> On Sat, 2019-10-05 at 09:50 -0600, Jens Axboe wrote:
>> On 10/5/19 4:12 AM, Mischa Baars wrote:
>>> Advised by the linux-next mailing list to repost this message on the linux-block mailing list:
>>>
>>> Hi,
>>>
>>> If I'm correct, packet writing support is going to be removed from the
>>> Linux kernel. Is there any particular reason for
>>> this, as far as you people know? Both DVD-writers and Blueray-writers are
>>> still being sold to date.
>>
>> The reasons are mostly that it's ancient technology and my doubt was
>> that nobody used it, and it's completely unmaintained code as well.
>>
> 
> How can it be ancient technology when CD-, DVD- and Blueray-writers
> are being sold by the thousands at this very moment? Floppy disk
> drives on the other hand were invented in 1967. This is the ancient
> technology you're looking for.

It's a suboptimal solution to the fact that devices were put to market
that required > page sized writes at the time. Hence pktcdvd sits in
between and ensures that we write out blocks that are big enough. If the
kernel supported > page size block sizes on file systems, pktdvd would
be superflous.

And please stops bringing up floppy, it's totally irrelevant to this
conversation.

>>> I'm currently working on quite a large project. I would be dependent
>>> solely on USB to store my backup files, when the packet writing support
>>> is removed. Actually I'm quite uncomfortable with that idea, because
>>> USB is rewritable. Any serious attempt to do damage to my project will
>>> result a permanent loss of code. Personally I would do anything to keep
>>> packet writing support in the kernel.
>>
>> If there are folks using the code (successfully), it's not going away.
>> But I can't quite tell from your email if you're just planning to use
>> it, or if you are using it already and it's working great for you?
>>
> 
> Yes, I've written the the code myself, thank you. It's prototype
> hardware and it's not intended as an open source software project. It
> is therefore not going to be released to the general public. When it's
> finished, and it isn't at the moment, it's hopefully going to be part
> of your future processors.

Let's keep this very simple:

1) Have you used the pktcdvd code at all? How much?
2) If yes to the first question, has it been stable?

> I did however find a enormous lot of bugs (in the kernel, the
> compiler, and in latex) since the project start, that deserve the
> attention of the opensource community. The bugs will come available to
> you in time. We can work on a better kernel and compiler together.

So bugs in pktcdvd? Or others parts?

>>> I'd hoped you could remove normal floppy disc support instead. That
>>> seems the more logical course of action. Floppy disc drives aren't
>>> being sold anymore for quite some years now.
>>
>> It's not really a case of quid pro quo, if someone gets removed,
>> something else can stay. I'd argue that the floppy driver is probably
>> used by orders of magnitude more people than the packet writing code,
>> and as such that makes it much more important to maintain.
>>
> 
> Who are you talking about? Are you asking to be removed? I'm afraid I
> don't quite understand.

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.

-- 
Jens Axboe


  reply	other threads:[~2019-10-06 15:10 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 [this message]
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
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=fc70b63f-3780-5654-6bc5-0f2d6115bff0@kernel.dk \
    --to=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.