Linux-Block Archive on lore.kernel.org
 help / color / Atom feed
* packet writing support
@ 2019-10-05 10:12 Mischa Baars
  2019-10-05 15:50 ` Jens Axboe
  0 siblings, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-05 10:12 UTC (permalink / raw)
  To: linux-block

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.

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.

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.

Anybody there?

Have a pleasant day,
Mischa Baars.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  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  8:31   ` Mischa Baars
  0 siblings, 2 replies; 22+ messages in thread
From: Jens Axboe @ 2019-10-05 15:50 UTC (permalink / raw)
  To: Mischa Baars, linux-block

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.

> 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?

> 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.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-05 15:50 ` Jens Axboe
@ 2019-10-06  7:31   ` Mischa Baars
  2019-10-06 15:10     ` Jens Axboe
  2019-10-06  8:31   ` Mischa Baars
  1 sibling, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-06  7:31 UTC (permalink / raw)
  To: Jens Axboe, linux-block

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.

> > 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.

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.

> > 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.

Regards,
Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-05 15:50 ` Jens Axboe
  2019-10-06  7:31   ` Mischa Baars
@ 2019-10-06  8:31   ` Mischa Baars
  2019-10-06 20:48     ` Laurence Oberman
  1 sibling, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-06  8:31 UTC (permalink / raw)
  To: Jens Axboe, linux-block

On Sat, 2019-10-05 at 09:50 -0600, Jens Axboe wrote:

> 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.

I'm not into time-reversal, if that is what you mean?! I love unilinear time and causal computers!

Regards,
Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-06  7:31   ` Mischa Baars
@ 2019-10-06 15:10     ` Jens Axboe
  2019-10-07  7:02       ` Mischa Baars
  0 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2019-10-06 15:10 UTC (permalink / raw)
  To: Mischa Baars, linux-block

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


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  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
  0 siblings, 2 replies; 22+ messages in thread
From: Laurence Oberman @ 2019-10-06 20:48 UTC (permalink / raw)
  To: Mischa Baars, Jens Axboe, linux-block

On Sun, 2019-10-06 at 10:31 +0200, Mischa Baars wrote:
> On Sat, 2019-10-05 at 09:50 -0600, Jens Axboe wrote:
> 
> > 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.
> 
> I'm not into time-reversal, if that is what you mean?! I love
> unilinear time and causal computers!
> 
> Regards,
> Mischa.
> 

Hello Mischa
Something is not making sense here.
If this will not be an open source project and not released then why
not simply snapshot the kernel as is now and go ahead.
Maintain it yourself, issue solved. No need to harp on the packet
writing code support anymore.

Many companies have taken a snap of the kernel to use for storage
arrays and then made changes and did not release the entire solution as
open source.

You said

"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.
"

Regards
Laurence Oberman


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-06 15:10     ` Jens Axboe
@ 2019-10-07  7:02       ` Mischa Baars
  2019-10-07  7:23         ` Hannes Reinecke
  2019-10-07 14:10         ` Jens Axboe
  0 siblings, 2 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  7:02 UTC (permalink / raw)
  To: Jens Axboe, linux-block

On Sun, 2019-10-06 at 09:10 -0600, Jens Axboe wrote:
> 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?

Where are talking about the kernel/drivers/block/pktcdvd.ko.xz module. I have not used it directly, as it is a kernel module. Instead I have been working with
K3b, the KDE cdwriting software package.

Quite a lot actually, let's say I have written about 11 * 25 cd's / dvd's in total. Without any problems. They are all still readable too, even after all this
time (about ten years). 

> 2) If yes to the first question, has it been stable?

Very stable if you ask me. Flawless even.

> > 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?

No, no bugs in pktcdvd. No fixing to do whatsoever.

> > > > 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.
> 

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?

Regards,
Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  7:02       ` Mischa Baars
@ 2019-10-07  7:23         ` Hannes Reinecke
  2019-10-07  8:07           ` Mischa Baars
  2019-10-07 14:10         ` Jens Axboe
  1 sibling, 1 reply; 22+ messages in thread
From: Hannes Reinecke @ 2019-10-07  7:23 UTC (permalink / raw)
  To: Mischa Baars, Jens Axboe, linux-block

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.

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?

Incidentally: I _do_ know of one company who happily will provide you
with a stable OS to base your development on ... three, actually ...

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  7:23         ` Hannes Reinecke
@ 2019-10-07  8:07           ` Mischa Baars
  2019-10-07  8:45             ` Hannes Reinecke
  0 siblings, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  8:07 UTC (permalink / raw)
  To: Hannes Reinecke, Jens Axboe, linux-block

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.

> 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?

> 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?

> Cheers,
> 
> Hannes


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-06 20:48     ` Laurence Oberman
@ 2019-10-07  8:10       ` Mischa Baars
  2019-10-07  9:02       ` Mischa Baars
  1 sibling, 0 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  8:10 UTC (permalink / raw)
  To: Laurence Oberman, linux-block

On Sun, 2019-10-06 at 16:48 -0400, Laurence Oberman wrote:
> On Sun, 2019-10-06 at 10:31 +0200, Mischa Baars wrote:
> > On Sat, 2019-10-05 at 09:50 -0600, Jens Axboe wrote:
> > 
> > > 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.
> > 
> > I'm not into time-reversal, if that is what you mean?! I love
> > unilinear time and causal computers!
> > 
> > Regards,
> > Mischa.
> > 
> 
> Hello Mischa
> Something is not making sense here.
> If this will not be an open source project and not released then why
> not simply snapshot the kernel as is now and go ahead.
> Maintain it yourself, issue solved. No need to harp on the packet
> writing code support anymore.
> 

You are mistaking my project for a kernel module. I do not intend to do a spinoff. Perhaps, if it were a kernel module, but it isn't.

> Many companies have taken a snap of the kernel to use for storage
> arrays and then made changes and did not release the entire solution as
> open source.
> 
> You said
> 
> "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.
> "
> 
> Regards
> Laurence Oberman
> 


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  8:07           ` Mischa Baars
@ 2019-10-07  8:45             ` Hannes Reinecke
  2019-10-07  9:11               ` Mischa Baars
  0 siblings, 1 reply; 22+ messages in thread
From: Hannes Reinecke @ 2019-10-07  8:45 UTC (permalink / raw)
  To: Mischa Baars, Jens Axboe, linux-block

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-06 20:48     ` Laurence Oberman
  2019-10-07  8:10       ` Mischa Baars
@ 2019-10-07  9:02       ` Mischa Baars
  1 sibling, 0 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  9:02 UTC (permalink / raw)
  To: Laurence Oberman, Jens Axboe, linux-block

On Sun, 2019-10-06 at 16:48 -0400, Laurence Oberman wrote:
> On Sun, 2019-10-06 at 10:31 +0200, Mischa Baars wrote:
> > On Sat, 2019-10-05 at 09:50 -0600, Jens Axboe wrote:
> > 
> > > 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.
> > 
> > I'm not into time-reversal, if that is what you mean?! I love
> > unilinear time and causal computers!
> > 
> > Regards,
> > Mischa.
> > 
> 
> Hello Mischa
> Something is not making sense here.
> If this will not be an open source project and not released then why
> not simply snapshot the kernel as is now and go ahead.
> Maintain it yourself, issue solved. No need to harp on the packet
> writing code support anymore.
> 
> Many companies have taken a snap of the kernel to use for storage
> arrays and then made changes and did not release the entire solution as
> open source.
> 
> You said
> 
> "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.
> "
> 
Actually I was saying something entirely different, wasn't I?

> Regards
> Laurence Oberman

Regards,
Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  8:45             ` Hannes Reinecke
@ 2019-10-07  9:11               ` Mischa Baars
  2019-10-07  9:17                 ` Mischa Baars
  2019-10-07 10:02                 ` Hannes Reinecke
  0 siblings, 2 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  9:11 UTC (permalink / raw)
  To: Hannes Reinecke, Jens Axboe, linux-block

On Mon, 2019-10-07 at 10:45 +0200, Hannes Reinecke wrote:
> 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.

Well, I was using it :(

Hope that isn't any problem?

> > > 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.

b) My point exactly, CD, DVD and Blueray is being replaced by USB Flash. The problem is, as you can read in my first mail, is that USB is rewritable. Also, I
can't even image that 100Gb Blueray is a thing of the past. Slots can be replaced by USB, but that doesn't make the writer obsolete.

No, I don't work for any company producing dvd and blueray drives.

a) If necesarry I could do the maintaining, sure.

> > > 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


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  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 10:02                 ` Hannes Reinecke
  1 sibling, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-07  9:17 UTC (permalink / raw)
  To: Hannes Reinecke, Jens Axboe, linux-block

On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
> necesarry

a) If necessary I could do the maintaining, sure.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  9:11               ` Mischa Baars
  2019-10-07  9:17                 ` Mischa Baars
@ 2019-10-07 10:02                 ` Hannes Reinecke
  1 sibling, 0 replies; 22+ messages in thread
From: Hannes Reinecke @ 2019-10-07 10:02 UTC (permalink / raw)
  To: Mischa Baars, Jens Axboe, linux-block

On 10/7/19 11:11 AM, Mischa Baars wrote:
> On Mon, 2019-10-07 at 10:45 +0200, Hannes Reinecke wrote:
>> 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.
> 
> Well, I was using it :(
> 
> Hope that isn't any problem?
> 
>>>> 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.
> 
> b) My point exactly, CD, DVD and Blueray is being replaced by USB Flash.
> The problem is, as you can read in my first mail, is that USB is rewritable. Also, I
> can't even image that 100Gb Blueray is a thing of the past. Slots can be
> replaced by USB, but that doesn't make the writer obsolete.
> 
Kingston 128GB USB flash, USD 15 per unit.
What was your question?

> 
> a) If neccesary I could do the maintaining, sure.
> 
Guess it is.
Please send a mail to Jens Axboe applying for pktdvd maintainership.

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07  7:02       ` Mischa Baars
  2019-10-07  7:23         ` Hannes Reinecke
@ 2019-10-07 14:10         ` Jens Axboe
  2019-10-07 14:19           ` Mischa Baars
  1 sibling, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2019-10-07 14:10 UTC (permalink / raw)
  To: Mischa Baars, linux-block

On 10/7/19 1:02 AM, Mischa Baars wrote:
>> Let's keep this very simple:
>>
>> 1) Have you used the pktcdvd code at all? How much?
> 
> Where are talking about the kernel/drivers/block/pktcdvd.ko.xz module.
> I have not used it directly, as it is a kernel module. Instead I have
> been working with K3b, the KDE cdwriting software package.

Let's keep it even simpler - why do you think you are using the pktcdvd
code at all? If you're using k3b to burn CDs or DVDs, then you are not
using that code at all. You'd have to actively setup a devie using
pktsetup, and you'd then mount it with UDF to write files. Doesn't sound
like what you are doing at all, which renders this whole discussion
pointless.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07 14:10         ` Jens Axboe
@ 2019-10-07 14:19           ` Mischa Baars
  0 siblings, 0 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07 14:19 UTC (permalink / raw)
  To: Jens Axboe, linux-block

On Mon, 2019-10-07 at 08:10 -0600, Jens Axboe wrote:
> On 10/7/19 1:02 AM, Mischa Baars wrote:
> > > Let's keep this very simple:
> > > 
> > > 1) Have you used the pktcdvd code at all? How much?
> > 
> > Where are talking about the kernel/drivers/block/pktcdvd.ko.xz module.
> > I have not used it directly, as it is a kernel module. Instead I have
> > been working with K3b, the KDE cdwriting software package.
> 
> Let's keep it even simpler - why do you think you are using the pktcdvd
> code at all? If you're using k3b to burn CDs or DVDs, then you are not
> using that code at all. You'd have to actively setup a devie using
> pktsetup, and you'd then mount it with UDF to write files. Doesn't sound
> like what you are doing at all, which renders this whole discussion
> pointless.
> 

I would not dare call it pointless. I have here a k3b application that has proven to work in the past, yet now it does not show any willingness to cooperate.
Until recently, I was still able to read CD's / DVD's from the filemanager, but since I installed the linux-next kernel, the driver doesn't even show up using
'fdisk -l' (with SCSI cdrom support compiled in).


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  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
  0 siblings, 2 replies; 22+ messages in thread
From: Bart Van Assche @ 2019-10-07 14:22 UTC (permalink / raw)
  To: Mischa Baars, Hannes Reinecke, Jens Axboe, linux-block

On 2019-10-07 02:17, Mischa Baars wrote:
> On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
>> necesarry
> 
> a) If necessary I could do the maintaining, sure.

You may want to start with having a look at the following:
* pktcdvd: invalid opcode 0000 kernel BUG in pkt_make_request
(https://bugzilla.kernel.org/show_bug.cgi?id=201481)
* pktcdvd triggers a lock inversion complaint
(https://bugzilla.kernel.org/show_bug.cgi?id=202745)

Thanks,

Bart.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07 14:22                   ` Bart Van Assche
@ 2019-10-07 14:36                     ` Mischa Baars
  2019-10-07 16:13                     ` Mischa Baars
  1 sibling, 0 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07 14:36 UTC (permalink / raw)
  To: Bart Van Assche, Hannes Reinecke, Jens Axboe, linux-block

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On Mon, 2019-10-07 at 07:22 -0700, Bart Van Assche wrote:
> On 2019-10-07 02:17, Mischa Baars wrote:
> > On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
> > > necesarry
> > 
> > a) If necessary I could do the maintaining, sure.
> 
> You may want to start with having a look at the following:
> * pktcdvd: invalid opcode 0000 kernel BUG in pkt_make_request
> (https://bugzilla.kernel.org/show_bug.cgi?id=201481)
> * pktcdvd triggers a lock inversion complaint
> (https://bugzilla.kernel.org/show_bug.cgi?id=202745)
> 
> Thanks,
> 
> Bart.

Hi Bart,

Unfortunately, I'm unable to reproduce your findings.

This is what shows up in my dmesg output:

[  166.135611] usb 1-6: new high-speed USB device number 5 using xhci_hcd
[  166.272735] usb 1-6: New USB device found, idVendor=0e8d, idProduct=1887, bcdDevice= 0.00
[  166.272749] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  166.272756] usb 1-6: Product: Portable Super Multi Drive
[  166.272762] usb 1-6: Manufacturer: Hitachi-LG Data Storage Inc
[  166.272767] usb 1-6: SerialNumber: K50H4EL4125         
[  166.543625] usb-storage 1-6:1.0: USB Mass Storage device detected
[  166.545207] scsi host2: usb-storage 1-6:1.0
[  166.545951] usbcore: registered new interface driver usb-storage
[  167.600103] scsi 2:0:0:0: CD-ROM            ASUS     SDRW-08D2S-U     A801 PQ: 0 ANSI: 0
[  167.605529] sr 2:0:0:0: Power-on or device reset occurred
[  167.611257] sr 2:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[  167.611269] cdrom: Uniform CD-ROM driver Revision: 3.20
[  167.615920] sr 2:0:0:0: Attached scsi CD-ROM sr0
[  167.616339] sr 2:0:0:0: Attached scsi generic sg0 type 5

Nothing strange, but when I do 'fdisk -l' nothing shows up. I'm not only unable to write, but also unable to read DVD's.

Regards,
Mischa.

[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 1040 bytes --]

[  166.135611] usb 1-6: new high-speed USB device number 5 using xhci_hcd
[  166.272735] usb 1-6: New USB device found, idVendor=0e8d, idProduct=1887, bcdDevice= 0.00
[  166.272749] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  166.272756] usb 1-6: Product: Portable Super Multi Drive
[  166.272762] usb 1-6: Manufacturer: Hitachi-LG Data Storage Inc
[  166.272767] usb 1-6: SerialNumber: K50H4EL4125         
[  166.543625] usb-storage 1-6:1.0: USB Mass Storage device detected
[  166.545207] scsi host2: usb-storage 1-6:1.0
[  166.545951] usbcore: registered new interface driver usb-storage
[  167.600103] scsi 2:0:0:0: CD-ROM            ASUS     SDRW-08D2S-U     A801 PQ: 0 ANSI: 0
[  167.605529] sr 2:0:0:0: Power-on or device reset occurred
[  167.611257] sr 2:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[  167.611269] cdrom: Uniform CD-ROM driver Revision: 3.20
[  167.615920] sr 2:0:0:0: Attached scsi CD-ROM sr0
[  167.616339] sr 2:0:0:0: Attached scsi generic sg0 type 5


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  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
  1 sibling, 1 reply; 22+ messages in thread
From: Mischa Baars @ 2019-10-07 16:13 UTC (permalink / raw)
  To: Bart Van Assche, Hannes Reinecke, Jens Axboe, linux-block

On Mon, 2019-10-07 at 07:22 -0700, Bart Van Assche wrote:
> On 2019-10-07 02:17, Mischa Baars wrote:
> > On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
> > > necesarry
> > 
> > a) If necessary I could do the maintaining, sure.
> 
> You may want to start with having a look at the following:
> * pktcdvd: invalid opcode 0000 kernel BUG in pkt_make_request
> (https://bugzilla.kernel.org/show_bug.cgi?id=201481)
> * pktcdvd triggers a lock inversion complaint
> (https://bugzilla.kernel.org/show_bug.cgi?id=202745)
> 
> Thanks,
> 
> Bart.

I'm unable to reproduce these findings, also I'm unable to find any executable or any manpage called pktsetup.

Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07 16:13                     ` Mischa Baars
@ 2019-10-07 16:19                       ` Jens Axboe
  2019-10-07 17:31                         ` Mischa Baars
  0 siblings, 1 reply; 22+ messages in thread
From: Jens Axboe @ 2019-10-07 16:19 UTC (permalink / raw)
  To: Mischa Baars, Bart Van Assche, Hannes Reinecke, linux-block

On 10/7/19 10:13 AM, Mischa Baars wrote:
> On Mon, 2019-10-07 at 07:22 -0700, Bart Van Assche wrote:
>> On 2019-10-07 02:17, Mischa Baars wrote:
>>> On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
>>>> necesarry
>>>
>>> a) If necessary I could do the maintaining, sure.
>>
>> You may want to start with having a look at the following:
>> * pktcdvd: invalid opcode 0000 kernel BUG in pkt_make_request
>> (https://bugzilla.kernel.org/show_bug.cgi?id=201481)
>> * pktcdvd triggers a lock inversion complaint
>> (https://bugzilla.kernel.org/show_bug.cgi?id=202745)
>>
>> Thanks,
>>
>> Bart.
> 
> I'm unable to reproduce these findings, also I'm unable to find any
> executable or any manpage called pktsetup.

Let's put this to rest. You are not using pktcdvd in your current setup.
You have apparently stumbled into some cdrom/dvd related regression if
the burning stopped working for you, please see:

Documentation/admin-guide/reporting-bugs.rst

in the kernel tree for how to report that bug, separately. No further
emails are needed in this thread.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: packet writing support
  2019-10-07 16:19                       ` Jens Axboe
@ 2019-10-07 17:31                         ` Mischa Baars
  0 siblings, 0 replies; 22+ messages in thread
From: Mischa Baars @ 2019-10-07 17:31 UTC (permalink / raw)
  To: Jens Axboe, Bart Van Assche, Hannes Reinecke, linux-block

On Mon, 2019-10-07 at 10:19 -0600, Jens Axboe wrote:
> On 10/7/19 10:13 AM, Mischa Baars wrote:
> > On Mon, 2019-10-07 at 07:22 -0700, Bart Van Assche wrote:
> > > On 2019-10-07 02:17, Mischa Baars wrote:
> > > > On Mon, 2019-10-07 at 11:11 +0200, Mischa Baars wrote:
> > > > > necesarry
> > > > 
> > > > a) If necessary I could do the maintaining, sure.
> > > 
> > > You may want to start with having a look at the following:
> > > * pktcdvd: invalid opcode 0000 kernel BUG in pkt_make_request
> > > (https://bugzilla.kernel.org/show_bug.cgi?id=201481)
> > > * pktcdvd triggers a lock inversion complaint
> > > (https://bugzilla.kernel.org/show_bug.cgi?id=202745)
> > > 
> > > Thanks,
> > > 
> > > Bart.
> > 
> > I'm unable to reproduce these findings, also I'm unable to find any
> > executable or any manpage called pktsetup.
> 
> Let's put this to rest. You are not using pktcdvd in your current setup.
> You have apparently stumbled into some cdrom/dvd related regression if
> the burning stopped working for you, please see:
> 
> Documentation/admin-guide/reporting-bugs.rst
> 
> in the kernel tree for how to report that bug, separately. No further
> emails are needed in this thread.
> 

Thanks, but I'd rather enjoy that which is gained by all this, than the fly in the ointment. At least people can't sell any cheap CD's with stolen software
anymore :)

Regards,
Mischa.


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, back to index

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

Linux-Block Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \
		linux-block@vger.kernel.org linux-block@archiver.kernel.org
	public-inbox-index linux-block

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block


AGPL code for this site: git clone https://public-inbox.org/ public-inbox