NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: port-amd64/53890: st(4) driver for tapes not working o variable block size
Hello Michael,
That is a very logical explanation.
For TAPE files -as long a I worked with them (52 years) they Always are odd
sized.
(besides the inter-system tapes - they had precise formats)
Now a patch and I will be happy.
I am and long time standing - 386BSD user.
Regards, Gerard.
PS, being careful is fine but not always...
-----Original Message-----
From: Michael van Elst [mailto:mlelstv%serpens.de@localhost]
Sent: Saturday, January 19, 2019 3:45 PM
To: port-amd64-maintainer%netbsd.org@localhost; gnats-admin%netbsd.org@localhost;
netbsd-bugs%netbsd.org@localhost; pa0gri%amsat.org@localhost
Subject: Re: port-amd64/53890: st(4) driver for tapes not working o variable
block size
The following reply was made to PR port-amd64/53890; it has been noted by GNATS.
From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: port-amd64/53890: st(4) driver for tapes not working o variable
block size
Date: Sat, 19 Jan 2019 14:42:42 -0000 (UTC)
pa0gri%amsat.org@localhost ("G J van der Grinten") writes:
>But on the recond read for a block I get an " Invalid argument" and that is
>invalid by itself.
Looks like this is not the tape driver itself. The kernel physio() routine
does a sanity check on the I/O byte offset to be a multiple of DEV_BSIZE
(== 512 bytes) and returns EINVAL if that's false. That's why the
second read or write fails (the first starts at offset 0).
That sanity check doesn't make sense for a tape and might not even be needed
for e.g. a disk, the disk drivers do their own checks.
--
--
Michael van Elst
Internet: mlelstv%serpens.de@localhost
"A potential Snark may lurk in every tree."
Home |
Main Index |
Thread Index |
Old Index