Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203225 > unrolled thread

About /dev/sr impatience with automatic tray loading

Back to article view | Back to linux.debian.user

Contents

  About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 15:00 +0100
    Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-10 16:00 +0100
      Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 18:50 +0100
        Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-10 20:00 +0100
          Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 21:10 +0100
            Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 01:20 +0100
              Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-11 12:40 +0100
                Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 18:00 +0100
                  Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-11 18:30 +0100
                    Re: About /dev/sr impatience with automatic tray loading Greg Wooledge <wooledg@eeg.ccf.org> - 2018-12-11 18:40 +0100
                      Re: About /dev/sr impatience with automatic tray loading Tony van der Hoff <lists@vanderhoff.org> - 2018-12-11 18:50 +0100
                        Re: About /dev/sr impatience with automatic tray loading John Hasler <jhasler@newsguy.com> - 2018-12-11 20:50 +0100
                      Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 20:30 +0100
            Re: About /dev/sr impatience with automatic tray loading mick crane <mick.crane@gmail.com> - 2018-12-11 13:40 +0100
              Re: About /dev/sr impatience with automatic tray loading Dan Ritter <dsr@randomstring.org> - 2018-12-11 15:50 +0100
                Re: About /dev/sr impatience with automatic tray loading Erik Christiansen <dvalin@internode.on.net> - 2018-12-12 01:10 +0100
                  Re: About /dev/sr impatience with automatic tray loading Dan Ritter <dsr@randomstring.org> - 2018-12-12 12:30 +0100
                    Re: About /dev/sr impatience with automatic tray loading David Wright <deblis@lionunicorn.co.uk> - 2018-12-12 21:20 +0100

#203225 — About /dev/sr impatience with automatic tray loading

Hi,

i'm starting this spin-off thread to avoid pollution of
  "dd: error reading '/dev/sr0': Input/output error"

I wrote:
> ... > (We have a bug in the kernel since 2008 which prevents waiting for
> ... > the drive to become ready after automatic tray loading.
> > The old timeout limit was 20 seconds. [...] So i'd propose 30 seconds

Gene Heskett wrote:
> I personally think thats a heck of a good idea. Someone with commit 
> rights should make it so.

First the consequences of commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734
need to be repaired. (I'd propose in drivers/cdrom/cdrom.c a dedicated
function named wait_for_medium_decision() to be called from existing
function open_for_data() instead of calling cdo->drive_status() directly.)

It's not about commit permission. It's about the well plausible rules laid
out at
  https://kernelnewbies.org/FoundBug
in paragraph "Has your bug been fixed ?". I need a newish kernel to prove
that the bug is still there and to test my proposed fix. (I tested that
it compiles and does not explode on a Sid VM with a virtual CD-ROM.)
The nature of the affected kernel module makes it necessary to develop
and test on real hardware. (My host /dev/sr4 always shows up as /dev/vda
on the VM if i try to forward it by virtio.)

Only then i could begin to beg for the attention of empowered people who
are willing to fix bugs which were planted by co-workers in an act of
drive-by programming. (One could have tested, back in 2008, instead of
making the failure look more plausible by commit
96bcc722c47d07b6fd05c9d0cb3ab8ea5574c5b1.)


> The best cd/dvd writer we have, k3b,

Cough. It is a frontend to burn programs like wodim, growisofs, cdrskin,
and maybe libburn, meanwhile. It also contains copied body parts of
such programs for doing its own media inspection.
Insofar it cannot be better at the core task of burning than its backend.


> cannot be told to verify its written 
> image because it times out way too fast at re-recognizing the ejected 
> and reloaded disk.  This has needed fixing since years ago.

Problem is that GUI programmers come and go.


Jude DaShiell wrote:
> > Why not prefix that dd command with a sudo udevadm settle command and
> > only allow the dd command to run on success case?

Gene Heskett wrote:
> Perhaps there is a place to configure that into k3b, and make a write 
> verify work?

The udev event queue is not involved in the kernel's perception of the
medium state. Currently the cdrom code does not wait for the drive to
indicate its readiness and thus emits error ENOMEDIUM as long as the drive
is still inspecting the freshly loaded medium.


I wrote:
> > I use:
> >   xorriso -outdev /dev/sr0
> > before trying to read the medium by POSIX i/o like dd(1) or read(2).

Gene Heskett wrote:
> This is also something that has not been installed till now, and has more 
> buttons than grandma's button jar.

But you don't need K3b to get your backup stuff done.

> But could it be configured into k3b for automatic usage?

We would have to find out why K3b fails. Did it eject the tray and re-load
it, before it tried to verify ?

If not, then it does not suffer from above kernel bug, but rather from
something else.

If the tray moved out and in, then it tries to work around the problem
of mixing POSIX i/o with writing via ioctl(SG_IO) by the burn backend.
Only tray loading forces the kernel to re-assess the new medium content.
(It would only need a small change in ioctl(BLKRRPART) to let it re-assess
 the content of a /dev/sr before bailing out because there is no partition
 table supposed to be assessed on /dev/sr. Like:
   https://www.spinics.net/lists/linux-block/msg22999.html
)
A workaround in K3b would be let it retry on error ENOMEDIUM for about
30 seconds and to only then give up.


Have a nice day :)

Thomas

[toc] | [next] | [standalone]

#203230

On Monday 10 December 2018 08:58:39 Thomas Schmitt wrote:


> I wrote:
[...]
> > > I use:
> > >   xorriso -outdev /dev/sr0
> > > before trying to read the medium by POSIX i/o like dd(1) or
> > > read(2).
>
> Gene Heskett wrote:
> > This is also something that has not been installed till now, and has
> > more buttons than grandma's button jar.
>
> But you don't need K3b to get your backup stuff done.
>
> > But could it be configured into k3b for automatic usage?
>
> We would have to find out why K3b fails. Did it eject the tray and
> re-load it, before it tried to verify ?
>
yes

> If not, then it does not suffer from above kernel bug, but rather from
> something else.
>
> If the tray moved out and in, then it tries to work around the problem
> of mixing POSIX i/o with writing via ioctl(SG_IO) by the burn backend.
> Only tray loading forces the kernel to re-assess the new medium
> content. (It would only need a small change in ioctl(BLKRRPART) to let
> it re-assess the content of a /dev/sr before bailing out because there
> is no partition table supposed to be assessed on /dev/sr. Like:
>    https://www.spinics.net/lists/linux-block/msg22999.html
> )
> A workaround in K3b would be let it retry on error ENOMEDIUM for about
> 30 seconds and to only then give up.
>
That ought to be doable, but would that not delay the ready by banging on 
the drive for a status report during that time? It only has so much cpu 
power.

Some of this ready delay may be due to drives today being able to handle 
more and more disk types than the basic CD, and configuring itself to 
use the correct parameters would extend that testing phase as it finds 
the correct configuration.  That makes sense to me at least.
>
> Have a nice day :)
>
> Thomas



-- 
Cheers, Thomas, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203238

Hi,

i wrote:
> > A workaround in K3b would be let it retry on error ENOMEDIUM for about
> > 30 seconds and to only then give up.

Gene Heskett wrote:
> That ought to be doable, but would that not delay the ready by banging on 
> the drive for a status report during that time? It only has so much cpu 
> power.

No. The drive works on its own after the tray went in (e.g. because
the kernel sent a START/STOP UNIT command). It inspects the medium
solely controlled by its built-in firmware.

The kernel or a burn program can only send a command TEST UNIT READY
from time to time. The answer may be that it is indeed ready for work,
or that it is still undecided, or that there is a problem like no medium
or incompatible medium.

Currently the kernel immediately indicates ENOMEDIUM to any userland
attempt to open the device until finally the drive is done with
inspecting the medium and found it acceptable.
Up to 2008 the kernel rather waited a short while and repeated the test
until the "still undecided" reply was gone or timeout occured. Only
then it answered to the attempt to open the device from userland.

(Exempted are open(2) calls with O_NONBLOCK/O_NDELAY which do not
 check for the drive status. They are for those who want contact to
 the drive, not to the medium on the first hand.)


A problem with a waiting loop in K3b would appear if the medium vanishes
between eject and re-load or has become incompatible by a drive mishap.
In this case K3b would wait 30 seconds in vain and could still not
decide whether the drive is stuck or the medium is gone.
But normally, the medium should still be there and the drive should be
able to decide within a due time that it is at least recognizable.

K3b could try to be smart and send own TEST UNIT READY commands to the
drive. It does more obtrusive things during its own media inspection.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#203242

On Monday 10 December 2018 12:46:41 Thomas Schmitt wrote:

> Hi,
>
> i wrote:
> > > A workaround in K3b would be let it retry on error ENOMEDIUM for
> > > about 30 seconds and to only then give up.
>
> Gene Heskett wrote:
> > That ought to be doable, but would that not delay the ready by
> > banging on the drive for a status report during that time? It only
> > has so much cpu power.
>
> No. The drive works on its own after the tray went in (e.g. because
> the kernel sent a START/STOP UNIT command). It inspects the medium
> solely controlled by its built-in firmware.
>
> The kernel or a burn program can only send a command TEST UNIT READY
> from time to time. The answer may be that it is indeed ready for work,
> or that it is still undecided, or that there is a problem like no
> medium or incompatible medium.
>
> Currently the kernel immediately indicates ENOMEDIUM to any userland
> attempt to open the device until finally the drive is done with
> inspecting the medium and found it acceptable.
> Up to 2008 the kernel rather waited a short while and repeated the
> test until the "still undecided" reply was gone or timeout occured.
> Only then it answered to the attempt to open the device from userland.
>
Perhaps that patch could be reverted, and the timeout made say 2 minutes, 
by which time the drive should be able to make up its mind that the 
media is readable, or that its truly duff because the burn wasn't good, 
laser failure or ??

I once did a complex lightscribe label, and apparently wiped out the 
laser. The label looked complete, but it never read or wrote another 
data side, and I went out to Wally's and bought another $26 drive. Which 
is still working well much of a decade later.

> (Exempted are open(2) calls with O_NONBLOCK/O_NDELAY which do not
>  check for the drive status. They are for those who want contact to
>  the drive, not to the medium on the first hand.)
>
>
> A problem with a waiting loop in K3b would appear if the medium
> vanishes between eject and re-load or has become incompatible by a
> drive mishap. In this case K3b would wait 30 seconds in vain and could
> still not decide whether the drive is stuck or the medium is gone.
> But normally, the medium should still be there and the drive should be
> able to decide within a due time that it is at least recognizable.
>
But the 30 seconds does not appear to be enough "due time", so it fails. 
Then a dd run to generate the sha1sum (or some suitable variety of sum) 
to verify the burn must be done as 2 separate operations, one to get the 
files sum and one to get the drives sum.

That I think we can all agree is a PITA.

> K3b could try to be smart and send own TEST UNIT READY commands to the
> drive. It does more obtrusive things during its own media inspection.
>
>
> Have a nice day :)
>
> Thomas

Thanks & take care, Thomas.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203248

Hi,

Gene Heskett wrote:
> Perhaps that patch could be reverted,

It had its legitimate intentions, 10 years ago.
See

  https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca861a915f734

and a glimpse of the following woes
  http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
(The culprits already suffered duely. Hehehe.)

The decisive change is not easy to spot. It's the loss of the function

    static int test_unit_ready(Scsi_CD *cd)

with the line

    return sr_do_ioctl(cd, &cgc);

sr_do_ioctl() has a waiting loop that eats "still undecided" replies and
retries at most 10 times. It still exists in the current kernel

  https://github.com/torvalds/linux/blob/master/drivers/scsi/sr_ioctl.c

where in line 223 ff. we can see the old timeout of 20 seconds

        if (!cgc->quiet)
                sr_printk(KERN_INFO, cd,
                          "CDROM not ready yet.\n");
        if (retries++ < 10) {
                /* sleep 2 sec and try again */
                ssleep(2);
                goto retry;
        } else {
                /* 20 secs are enough? */
                err = -ENOMEDIUM;
                break;
        }

The replacement for test_unit_ready() is a call to scsi_test_unit_ready()
which does not call a function with retry loop.

For the purpose of sr_drive_status(), the loop is really inappropriate.
This function shall obtain the drive status and not wait until the
status of the medium is decided.

Regrettably the subsequent correction attempts never reached the doings
of drivers/cdrom/cdrom.c function open_for_data(). By the original
change it lost its loop and never got a new one.

My fix proposal is to create a function with such a loop and to let
open_for_data() use it instead of the call of cdo->drive_status(),
which actually is sr_drive_status().
Currently this call is in line 1068 of

  https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c


> and the timeout made say 2 minutes, 
> by which time the drive should be able to make up its mind

30 seconds seems to be enough for all normal situations. My longest
experiment result with various drives and media was 18 seconds.
One would have to convince the hypothetical committer why 120 is needed.

But before commit comes the test and before test comes the recent kernel
on real iron. I only have code for now and feel fewly talented for the
missing steps.


> That I think we can all agree is a PITA.

Oh. I know some more such dumplings.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#203260

On Monday 10 December 2018 15:02:44 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > Perhaps that patch could be reverted,
>
> It had its legitimate intentions, 10 years ago.
> See
>
>  
> https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca
>861a915f734
>
> and a glimpse of the following woes
>   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> (The culprits already suffered duely. Hehehe.)

And rather than fix it, walked away.
>
> The decisive change is not easy to spot. It's the loss of the function
>
>     static int test_unit_ready(Scsi_CD *cd)
>
> with the line
>
>     return sr_do_ioctl(cd, &cgc);
>
> sr_do_ioctl() has a waiting loop that eats "still undecided" replies
> and retries at most 10 times. It still exists in the current kernel
>
>  
> https://github.com/torvalds/linux/blob/master/drivers/scsi/sr_ioctl.c
>
> where in line 223 ff. we can see the old timeout of 20 seconds
>
>         if (!cgc->quiet)
>                 sr_printk(KERN_INFO, cd,
>                           "CDROM not ready yet.\n");
>         if (retries++ < 10) {
>                 /* sleep 2 sec and try again */
>                 ssleep(2);
>                 goto retry;
>         } else {
>                 /* 20 secs are enough? */
>                 err = -ENOMEDIUM;
>                 break;
>         }
>
> The replacement for test_unit_ready() is a call to
> scsi_test_unit_ready() which does not call a function with retry loop.
>
> For the purpose of sr_drive_status(), the loop is really
> inappropriate. This function shall obtain the drive status and not
> wait until the status of the medium is decided.
>
> Regrettably the subsequent correction attempts never reached the
> doings of drivers/cdrom/cdrom.c function open_for_data(). By the
> original change it lost its loop and never got a new one.
>
> My fix proposal is to create a function with such a loop and to let
> open_for_data() use it instead of the call of cdo->drive_status(),
> which actually is sr_drive_status().
> Currently this call is in line 1068 of
>
>   https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c
>
> > and the timeout made say 2 minutes,
> > by which time the drive should be able to make up its mind
>
> 30 seconds seems to be enough for all normal situations. My longest
> experiment result with various drives and media was 18 seconds.
> One would have to convince the hypothetical committer why 120 is
> needed.
>
I expect you have a better understanding than I do.  What I will say is 
if you fix it, there will be flowery words written by several, and a 
hand cooler offered if you show up at my place thirsty.

> But before commit comes the test and before test comes the recent
> kernel on real iron. I only have code for now and feel fewly talented
> for the missing steps.
>
> > That I think we can all agree is a PITA.
>
> Oh. I know some more such dumplings.
>
So do I, Thomas, but this is supposedly a polite list. :)
>
> Have a nice day :)
>
> Thomas



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203263

Hi,

i wrote:
> > I know some more such dumplings.

Gene Heskett wrote:
> So do I, Thomas, but this is supposedly a polite list. :)

I actually meant the bugs, not the bug makers whose sympathy is probably
needed to ever get the bugs fixed.
(When pointing with one finger at others, three fingers are pointing back
 to oneself ...)

The tray loading bug is not as embarrassing as the SG_IO concurrency bug
(two concurrent burns on different /dev/sr are awfully slow) and the
CD read-ahead bug (i/o errors when trying to read valid blocks near
the end of a CD that was written with write type Track-At-Once).


> >   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> > (The culprits already suffered duely. Hehehe.)

> And rather than fix it, walked away.

They fixed several negative consequences of the necessary change.
But obviously they did not assess all callers of sr_drive_status() whether
they depended on the loop at its inappropriate position in the code.
I did not, either, but only found one left-over and needed several
curious attempts during 2.5 years to finally understand what happened.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#203277

On Tuesday 11 December 2018 06:25:43 Thomas Schmitt wrote:

> Hi,
>
> i wrote:
> > > I know some more such dumplings.
>
> Gene Heskett wrote:
> > So do I, Thomas, but this is supposedly a polite list. :)
>
> I actually meant the bugs, not the bug makers whose sympathy is
> probably needed to ever get the bugs fixed.

+1 :)

> (When pointing with one finger at others, three fingers are pointing
> back to oneself ...)
>
Absolutely.

> The tray loading bug is not as embarrassing as the SG_IO concurrency
> bug (two concurrent burns on different /dev/sr are awfully slow) and
> the CD read-ahead bug (i/o errors when trying to read valid blocks
> near the end of a CD that was written with write type Track-At-Once).
>
> > >   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> > > (The culprits already suffered duely. Hehehe.)
> >
> > And rather than fix it, walked away.
>
> They fixed several negative consequences of the necessary change.
> But obviously they did not assess all callers of sr_drive_status()
> whether they depended on the loop at its inappropriate position in the
> code. I did not, either, but only found one left-over and needed
> several curious attempts during 2.5 years to finally understand what
> happened.
>
And you've obviously worn that detective hat, with better tools that I.
>
> Have a nice day :)

Yourself too Thomas. I see by gkrellm that we may have a slow thaw, its 
up to 0.6C, at the airport 16 miles northeast and I may be able to put 
the finishing cuts on a back box panel that will bring my bigger milling 
machine back to life eventually. Not a lot of heat in that building with 
its small machines though. Just enough to keep the machinery above the 
dew point and major rusting, but not enough to keep my diabetic feet 
warm. One of the hazards of the ultimate revenge, outliveing ones last 
enemy by a decade+. ;-)

> Thomas

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203278

Hi,

i wrote:
> > This function shall obtain the drive status and not wait until the
> > status of the medium is decided.

mick crane wrote:
> I have noticed that people whose first language might not be english use
> "shall" as apposed to "will" or "should".

The topic has its own wikipedia article:
  https://en.wikipedia.org/wiki/Shall_and_will

In german it is "soll" (= shall/demanding), "sollte" (= should/proposing),
and "wird" (= will/predicting or shall/predicting).

I meant it in the way of technical specification of purpose.


Dan Ritter wrote:
> The English use it more than Americans do.

In school it was a big deal to distinguish "will" and "shall".
(I was very eager to forget the exact rules when nobody cared any more.)


I wrote:
> > I [...] needed several curious attempts during 2.5 years to finally
> > understand what happened.

Gene Heskett wrote:
> with better tools that I.

Only fgrep in local /usr/src/linux-source-3.16 and linux-4.1.6 and
Iceweasel were involved.

In the end it was about reading all commits to sr.c, sr_ioctl.c, and
cdrom.c since the release of kernel 2.6.18 (where i knew that the bug
was not in) up to 3.16 (where i first experienced the bug).
Like
  https://github.com/torvalds/linux/commits/master/drivers/scsi/sr.c

As said, i was very curious.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#203280

On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
> Dan Ritter wrote:
> > The English use it more than Americans do.
> 
> In school it was a big deal to distinguish "will" and "shall".
> (I was very eager to forget the exact rules when nobody cared any more.)

Americans (at least in my part of the country) never use "shall" at
all.  To us, it simply sounds archaic.  We'd expect it in the King James
Bible, or in certain kinds of fantasy literature.

[toc] | [prev] | [next] | [standalone]

#203281

On 11/12/18 17:31, Greg Wooledge wrote:
> On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
>> Dan Ritter wrote:
>>> The English use it more than Americans do.
>>
>> In school it was a big deal to distinguish "will" and "shall".
>> (I was very eager to forget the exact rules when nobody cared any more.)
> 
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King James
> Bible, or in certain kinds of fantasy literature.
> 

Not the bible, but pretty close:
https://www.ietf.org/rfc/rfc2119.txt


-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]

#203284

Greg writes:
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King James
> Bible, or in certain kinds of fantasy literature.

I might use it in a question but other uses are archaic except in a
legalistic context such as an RFC.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#203282

On Tuesday 11 December 2018 12:31:46 Greg Wooledge wrote:

> On Tue, Dec 11, 2018 at 06:22:56PM +0100, Thomas Schmitt wrote:
> > Dan Ritter wrote:
> > > The English use it more than Americans do.
> >
> > In school it was a big deal to distinguish "will" and "shall".
> > (I was very eager to forget the exact rules when nobody cared any
> > more.)
>
> Americans (at least in my part of the country) never use "shall" at
> all.  To us, it simply sounds archaic.  We'd expect it in the King
> James Bible, or in certain kinds of fantasy literature.

Or in legal here in the US, where "may" tends to mean never for 
personal/political reasons on the part of the county official in charge 
and "shall" says will without a personal choice in the matter. We only 
changed one word in a law from may to shall, 20+ years ago which the 
same statewide. That was huge.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#203265

On 2018-12-10 20:02, Thomas Schmitt wrote:
> Hi,
> 
> Gene Heskett wrote:
>> Perhaps that patch could be reverted,
> 
> It had its legitimate intentions, 10 years ago.
> See
> 
> 
> https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca861a915f734
> 
> and a glimpse of the following woes
>   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> (The culprits already suffered duely. Hehehe.)
> 
> The decisive change is not easy to spot. It's the loss of the function
> 
>     static int test_unit_ready(Scsi_CD *cd)
> 
> with the line
> 
>     return sr_do_ioctl(cd, &cgc);
> 
> sr_do_ioctl() has a waiting loop that eats "still undecided" replies 
> and
> retries at most 10 times. It still exists in the current kernel
> 
>   https://github.com/torvalds/linux/blob/master/drivers/scsi/sr_ioctl.c
> 
> where in line 223 ff. we can see the old timeout of 20 seconds
> 
>         if (!cgc->quiet)
>                 sr_printk(KERN_INFO, cd,
>                           "CDROM not ready yet.\n");
>         if (retries++ < 10) {
>                 /* sleep 2 sec and try again */
>                 ssleep(2);
>                 goto retry;
>         } else {
>                 /* 20 secs are enough? */
>                 err = -ENOMEDIUM;
>                 break;
>         }
> 
> The replacement for test_unit_ready() is a call to 
> scsi_test_unit_ready()
> which does not call a function with retry loop.
> 
> For the purpose of sr_drive_status(), the loop is really inappropriate.
> This function shall obtain the drive status and not wait until the
> status of the medium is decided.
> 
> Regrettably the subsequent correction attempts never reached the doings
> of drivers/cdrom/cdrom.c function open_for_data(). By the original
> change it lost its loop and never got a new one.
> 
> My fix proposal is to create a function with such a loop and to let
> open_for_data() use it instead of the call of cdo->drive_status(),
> which actually is sr_drive_status().
> Currently this call is in line 1068 of
> 
>   https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c
> 
> 
>> and the timeout made say 2 minutes,
>> by which time the drive should be able to make up its mind
> 
> 30 seconds seems to be enough for all normal situations. My longest
> experiment result with various drives and media was 18 seconds.
> One would have to convince the hypothetical committer why 120 is 
> needed.
> 
> But before commit comes the test and before test comes the recent 
> kernel
> on real iron. I only have code for now and feel fewly talented for the
> missing steps.
> 
> 
>> That I think we can all agree is a PITA.
> 
> Oh. I know some more such dumplings.
> 
> 
> Have a nice day :)
> 
> Thomas

completely off the topic but I have noticed that people whose first 
language might not be english use
"shall" as apposed to "will" or "should". It seems a little bit old 
fashioned but maybe it isn't.
Like some check list of an experiment approached logically.
Just something I was curious about.

"This function shall obtain the drive status and not wait until the
status of the medium is decided."


mick
-- 
Key ID    4BFEBB31

[toc] | [prev] | [next] | [standalone]

#203271

mick crane wrote: 
> On 2018-12-10 20:02, Thomas Schmitt wrote:
> > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > This function shall obtain the drive status and not wait until the
> > status of the medium is decided.
> > 
 
> completely off the topic but I have noticed that people whose first language
> might not be english use
> "shall" as apposed to "will" or "should". It seems a little bit old
> fashioned but maybe it isn't.

The English use it more than Americans do.

"Shall" has a connotation of ordering future action. Americans
nearly always prefer "should".

"Will" is a prediction of future action. 

"Should" is a desire for future action, with an acknowledgment
that it might not go that way. In a question, it asks for
advice on desirability.

"May" is a speculation on future action, with less certainty and
less imputed desire. In a question it asks for permission.

"Can" is a description of a possible future action, and
sometimes carries the connotation that the action is
appropriate. Americans like to use this instead of "may", but
they generally know that "may" is permission and "can" is
capability.

"Might" is either used to request permission or to describe a
low-probability future action. Americans rarely use this this
in question form.

-dsr- (American/British hybrid)

[toc] | [prev] | [next] | [standalone]

#203292

On 11.12.18 09:44, Dan Ritter wrote:
> mick crane wrote: 
> > On 2018-12-10 20:02, Thomas Schmitt wrote:
> > > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > > This function shall obtain the drive status and not wait until the
> > > status of the medium is decided.
> > > 
>  
> > completely off the topic but I have noticed that people whose first language
> > might not be english use
> > "shall" as apposed to "will" or "should". It seems a little bit old
> > fashioned but maybe it isn't.
> 
> The English use it more than Americans do.
> 
> "Shall" has a connotation of ordering future action. Americans
> nearly always prefer "should".

Here down under, my exposure to "shall" over the last four decades has
primarily been in communications products specifications, where it meant
"must" as far as we the system designers and implementers were concerned.
"Should" would not be an adequate substitute, I think, where failure to
comply is breach of contract.

Erik

[toc] | [prev] | [next] | [standalone]

#203304

Erik Christiansen wrote: 
> On 11.12.18 09:44, Dan Ritter wrote:
> > mick crane wrote: 
> > > On 2018-12-10 20:02, Thomas Schmitt wrote:
> > > > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > > > This function shall obtain the drive status and not wait until the
> > > > status of the medium is decided.
> > > > 
> >  
> > > completely off the topic but I have noticed that people whose first language
> > > might not be english use
> > > "shall" as apposed to "will" or "should". It seems a little bit old
> > > fashioned but maybe it isn't.
> > 
> > The English use it more than Americans do.
> > 
> > "Shall" has a connotation of ordering future action. Americans
> > nearly always prefer "should".
> 
> Here down under, my exposure to "shall" over the last four decades has
> primarily been in communications products specifications, where it meant
> "must" as far as we the system designers and implementers were concerned.
> "Should" would not be an adequate substitute, I think, where failure to
> comply is breach of contract.

Indeed, in legal and technical language, "shall" and "will" are orders
for compliance.  In ordinary speech and writing, though, "You shall take
the recycling bin to the street" vs "You should take the recycling bin
to the street" -- Americans will never say the former. Well, I
would, but ...


-dsr-

[toc] | [prev] | [next] | [standalone]

#203323

On Wed 12 Dec 2018 at 06:27:06 (-0500), Dan Ritter wrote:
> Erik Christiansen wrote: 
> > On 11.12.18 09:44, Dan Ritter wrote:
> > > mick crane wrote: 
> > > > On 2018-12-10 20:02, Thomas Schmitt wrote:
> > > > > For the purpose of sr_drive_status(), the loop is really inappropriate.
> > > > > This function shall obtain the drive status and not wait until the
> > > > > status of the medium is decided.
> > > > > 
> > >  
> > > > completely off the topic but I have noticed that people whose first language
> > > > might not be english use
> > > > "shall" as apposed to "will" or "should". It seems a little bit old
> > > > fashioned but maybe it isn't.
> > > 
> > > The English use it more than Americans do.
> > > 
> > > "Shall" has a connotation of ordering future action. Americans
> > > nearly always prefer "should".
> > 
> > Here down under, my exposure to "shall" over the last four decades has
> > primarily been in communications products specifications, where it meant
> > "must" as far as we the system designers and implementers were concerned.
> > "Should" would not be an adequate substitute, I think, where failure to
> > comply is breach of contract.
> 
> Indeed, in legal and technical language, "shall" and "will" are orders
> for compliance.  In ordinary speech and writing, though, "You shall take
> the recycling bin to the street" vs "You should take the recycling bin
> to the street" -- Americans will never say the former. Well, I
> would, but ...

I think it's very dependent on time and place. Looking at the "shall
and will" wiki page, I was brought up (English, 1950s) with the
so-called traditional prescriptive grammar rules where the 1st person
is treated differently.

You can avoid the problem by contracting both to "'ll", but that
doesn't work too well for objects. Perhaps one day "'ll" will take on
a life of its own, like "'ve" (spelled "of") has.

One thing on that wiki page did surprise me—that "shan't" is rarely
used in N America, and dwindling elsewhere. I thought every child
shouted "Shan't!" when they reached a certain age. "Won't!" is such
a poor substitute, starting as it does with a w.

As for legal documents, it's perhaps best left to the lawyers: big
cases have hinged on things like shall, the Oxford comma, etc.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web