ESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) (10/19/87)
There are a few problems which I've noticed concerning SHAR difference
archives/files being sent around the system over the past months.
i. The files are mainly created using PC-IX tools, UNIX, XENIX, but
rarely MINIX. This obviously affects the compatibility of the
transfers. Isn't it possible for development to be done under
MINIX or at least _tested_ under MINIX before being distributed
to the world (or the MINIX world in any case)?
ii. I've compiled my version of 'sed' (eventually after increasing
the stack space of 'sh' and performing a manual 'asld' to get
around the RAM disc overflow (by using an 'asld' -T. option).
However... the 'sed' call doesn't seem to work too well. It
truncates some of the files at strange places and leaves most
of them completely empty. My guess is that most people using
these SHAR files are either using a DOS utility they've written
themselves to break them up, or are going through a long-winded
session with some editor. It seems a pity because the SHAR files
are designed specifically to allow easy unpacking.
iii. The checksums on the files are completely useless at the moment.
This is probably due to the fact that lines over 80 characters
are split up by most mailers, tab/space combinations go through
numerous comversions, and heaven knows what else. The checksum
test ALWAYS fails when I try to unSHAR my files.
iv. The FIX program simply calls 'strcmp', but due to the tab/space
(etc) problem(s) mentioned in (iii) above, it nearly always fails
the test even when it SHOULD pass. The solution is to write a
replacement 'strcmp' which ignores differing white-space characters,
but the solution is not ideal.
Is anyone out there finding similar problems (and I'm pretty sure you are!),
and has anyone got any solutions, ideas, etc. as to how the problem may be
solved?
Also - has anyone actually got a completely working, tested version of the
Turbo-C MINIX 1.2 for which the differences were recently distributed? If
so, I'd be grateful to hear of any problems you encountered, and how you
got around them. I'm in the very long and tedious process of applying the
differences - the problems mainly caused by the points mentioned above.
Karl Keyteegisin@orchid.UUCP (10/21/87)
In article <609@louie.udel.EDU>, ESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) writes: > iii. The checksums on the files are completely useless at the moment. > This is probably due to the fact that lines over 80 characters > are split up by most mailers, tab/space combinations go through > numerous comversions, and heaven knows what else. The checksum > test ALWAYS fails when I try to unSHAR my files. This is a problem with BITNET. This is another reason for splitting comp.os.minix into discussion and source groups; the source group could be uuencoded when redistributed to bitnet. I don't think there is any need to moderate a minix source group.
stuff@crash.CTS.COM (David Yip) (10/21/87)
I had the same problem with sed. I fixed it by outputing a null character instead of the debugging messages. I have no idea why this works. The sums seemmed to be correct now. There is still a problem though. With certain shar files, minix seems to 'lock up' and it says that there is a process called 'racing' when F1 is hit. What does 'racing' mean?
NU070156@NDSUVM1.BITNET (Glen Overby) (10/21/87)
In article <609@louie.udel.EDU>, ESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) says: > [...] My guess is that most people using > these SHAR files are either using a DOS utility they've written > themselves to break them up, or are going through a long-winded > session with some editor. It seems a pity because the SHAR files > are designed specifically to allow easy unpacking. Or using a real Unix system, like me (4.3BSD on a VAX 11/780). I have successfully used 'gres' to remove the beginning of line pad characters that most people put on to sneak around gateways. That minimises your edit session. > iii. The checksums on the files are completely useless at the moment. > This is probably due to the fact that lines over 80 characters > are split up by most mailers, tab/space combinations go through > numerous comversions, and heaven knows what else. The checksum > test ALWAYS fails when I try to unSHAR my files. That is the fault of your (our--I'm stuck on Bitnet also) network. Either fix the network or live with it; there is no reason to ask the rest of the world to compensate for the brain dammage that you inflict upon yourself by using IBM. I have been able to minimize this dammage by taking the Minix sources off of our NETNEWS feed over bitnet; it allows 132 columns (one printer line, rather than one punched card) and using Larry Wall's "patch" with the 'loose' (-l) option. Get on a real computer on a real network and your problems will diminish. Glen Overby Bitnet: nu070156@ndsuvm1 UUCP: uunet!ndsuvax!ncoverby
jaime@killer.UUCP (James Dasilva) (10/21/87)
In article <609@louie.udel.EDU> ESC1332%ESOC.BITNET@wiscvm.wisc.edu (K.Keyte) writes: > ii. I've compiled my version of 'sed' (eventually after increasing > the stack space of 'sh' and performing a manual 'asld' to get > around the RAM disc overflow (by using an 'asld' -T. option). > However... the 'sed' call doesn't seem to work too well. It > truncates some of the files at strange places and leaves most > of them completely empty. The problem is in exit(), not sed. Put a flush() before each exit() in the sed sources and you should be fine. > iv. The FIX program simply calls 'strcmp', but due to the tab/space > (etc) problem(s) mentioned in (iii) above, it nearly always fails > the test even when it SHOULD pass. The solution is to write a > replacement 'strcmp' which ignores differing white-space characters, > but the solution is not ideal. I have not yet had this problem, but it does seem that a version of fix that ignores differences in whitespace IS a good solution to the problem, barring fixing every mailer in use. Patch does this, doesn't it? Using the Minix 1.2 shell with the data area set to 32000 bytes, sed with the described fix, and the version of chmod that I posted to the net, I have been able to successfully unshar every shar that I have attempted, including all of ast's 1.2 "Definitive Update". I have not attempted the Turbo-C patches, however. James da Silva UUCP: ihnp4!killer!jaime
cox%v70nl.decnet@nusc.arpa (V70NL::COX) (12/04/87)
For those people having problems extracting shar archives within MINIX, there is another alternative to obtaining sed or simply hacking the archive apart. The grep command will do the same thing that sed does in the context of a shar archive. You also need to modify the arguments to chmod in the archive (unless you are using the modified chmod) since chmod only accepts numeric arguments. The following method does the trick. Create a file (fix.sh) containing the line: gres "sed 's/\^X//'" "gres '^X' ''" $1 | gres "'u=rw,g=r,o=r'" 644 >$1.new Then, typing "sh fix.sh archive" creates archive.new which uses gres instead of sed, and works with the old chmod. One requirement for fix.sh to work is the version 1.2 shell. When I used the 1.1 shell, gres couldn't recognize the \^ sequence properly. If this is the case, simply perform the above replacements with mined. (Split the archive if it is too large to use mined.) The 1.1 shell also runs out of string space quickly with large archives. In this case, increasing the shell stack size with chmem works unless the archive is still too large. Hope this helps. - Bob Cox (cox@nusc.arpa) ------
MDOELL%DOSUNI1.BITNET@cunyvm.cuny.edu (Magnus Doell) (10/03/90)
Hello world!
Following is a brief description of my SCSI driver, I have written
quick-and-dirty nearly a year ago, first with a Storage Dynamics T-1007
SCSI hostadapter, now with Seagates ST-02.
This driver has nothing to do with the one Fred has posted a few days
ago, but this description may help you in understanding it (I don't know,
as I couldn't uud it - uud grumbled something about duplicate char in
translation table and I am grumbling to |-).
RUNNING ENVIRONMENT
The driver is now running with the following hardware configuration:
16 MHz 386sx
Seagates ST-02 SCSI hostadapter
Seagates ST296N 80 MByte harddisk as SCSI device 0
(a few days ago, I have added a second harddisk for testing only)
Control Datas WREN IV CDC 94171 300 MByte harddisk as SCSI device 1
but it should be configurable to run on other hardware environments also.
GENERAL NOTES
Before I start with the description of my driver, let me state out one point
or another here explicitly:
1. This driver isn't designed to be an optimal driver for a specific SCSI
hostadapter, but to be configurable to as many SCSI hostadapters as possible
with only minor changes (for this reason, it couldn't use the controllers
special features like programmed DMA, interrupts etc. |-( but it could be
a workable starting point for such an optimized driver).
2. This driver isn't finished yet |-( I have a somewhat ideallistic layout
for the finished version, from which this driver is now far away |-) but I
am now searching for pre-beta-testers, so I could include missing features
as well as other hardware environments, to which this driver may be
configurable or definitely won't. For this reason, I won't post the driver
yet, but mail it to the pre-beta-testers (all interested peoples are welcome)
as long as the list isn't to great (in which case I'll post it however).
3. I am willing to give Andy all the rights he needs to add this driver
to coming versions of MINIX (are you interested, Andy) with all the
configurations coming from the net (so if you want to (pre-)beta-test this
driver on your hardware configuration, you should also be willing to mail
me your changes/extensions/configurations and give me all the rights neccessary
to build them into the final version).
4. There should be at least 2 extensions to MINIX outside this driver to
increase the throughput drastically in some circumstances, including:
a) 2 routines in klib.x for reading/writing multiple bytes from an I/O port
b) a better interface for tasks to install watchdog-functions within the
clock driver, avoiding the message-passing overhead and -more important-
handling the pending ticks accordingly (this driver needs timings in dozends
of milliseconds and the clock driver is designed to handle timings in seconds,
although times are specified in ticks).
(I haven't implemented this extensions yet, but use a poor timeout mechanism
with a counter instead |-( and I won't implement them until I have your O.K.,
Andy).
5. As this driver is based on informations I found in some german computer
magazines (named c't and mc, many thanks to them for these articles) and a
close look with a debugger to the different controllers BIOSes (to get
informations about the controllers mappings) not using the ANSI draft proposal
X-3T9.2 (I don't know, where to get it - could anybody tell me?) nor any
technical handbook for the different controllers or harddisks, I may have
misunderstand something (and so will the driver now) as well as there are
some missing features (like forcing messages to targets and all the thinks
only related to disconnections and reselections).
THE SCSI HOSTADAPTER
The SCSI hostadapter should map (parts of) the SCSI bus more or less directly
into the processors address space, leaving the driver the job to check and
activate the SCSI bus lines directly with only minor helps on some very time
critical actions (it won't be wrong to assume, that the hostadapter's
architecture is designed to minimize the accesses to the mapped SCSI bus).
I have decided to devide (somewhat arbitrary but not uncommon) this mapping
into 3 parts:
part 1 are (parts of) the SCSI bus handshake signals as well as all the
signals needed to determine any legal SCSI bus phase. I will name
this part "status register(s)".
part 2 are (parts of) the SCSI bus handshake signals as well as all the
signals needed to bring the SCSI bus into any legal SCSI bus phase.
I will name this part "command register(s)".
part 3 are all the SCSI bus data lines. I will name this part the "data
register" (only one, although it could be mirrored for easier access
when it is memory mapped into the processors address space).
All this parts may be independandly mapped into the processors address
space (even in different types of address spaces, although it is bad design
style, to map part one and two into different address space types).
Part two does contain all the neccessary SCSI bus lines (or some the SCSI bus
lines controlling switches) as well as it may also contains some other switches
(e.g. a switch for connecting/disconnecting the registers to the SCSI bus).
The driver is designed to use a minimum set of SCSI bus lines, so that it
shouldn't be dramatic, if your hostadapter is missing one SCSI line or the
other in the mapping (e.g. the driver doesn't use arbitration, as the
attention line may be missing).
THE DRIVERS OVERALL STRUCTURE
The driver is devided into 4 layers (or at least should be).
layer 0 realizes the access of the different controllers registers by defining
the access mechanism in terms of routines found elsewhere in MINIX
(e.g. phys_copy for memory mapped registers, port_in, port_out etc.
for I/O mapped registers). It also defines the registers's addresses,
masks, status values and command values. To be more precise, it
defines a set of symbolic names for register addresses, values for
masking, checking and setting for each SCSI bus phase to be used
in layer 1 as well as some more general values (e.g. for detecting
the SCSI's bus phase etc.).
layer 1 is a collection of routines each handling one SCSI bus phase together
with some utility routines for more convenience and error recovery.
The routines access the SCSI hostadapter only through layer 0 and
upper layers should access it only through layer 1, so a configuration
should be restricted to layer 0 in most cases.
The routines in this layer assume, that the accesses to the
hostadapter's data register also handle the neccessary SCSI bus
acknoledgement (this is the point, where accesses to the hostadapter's
registers are minimized).
They all do busy waiting on the SCSI bus (whereas some may avoid
this busy waiting others can't without using special features from
the hostadapter), so they should be called from upper layers, when
these are awaiting the corresponding SCSI bus phase soon.
For now I have implemented a poor timeout mechanism, which I will
reimplement, when I am adding the missing features to MINIX.
I will also add the abilty to specify some timeout values in upper
layers as they may vary highly on the devices and this layer shouldn't
assume too much on the devices attached to the SCSI bus (but for
now it actually assumes quick harddisks |-).
layer 2 isn't yet existing but should implement the SCSI's common command set.
For now I have special versions for some group 0 and one group 1
command built-in in layer 3.
I have decided to implement this special versions also busy waiting
for 3 reasons:
a) it is easier to implement |-)
b) as the filesystem is blocked waiting for the driver to finish,
it may be better to finish as quick as possible than to avoid
busy waiting - or at least it shouldn't slow it down dramatically
c) as I have only harddisks to control and these are quick, I could
live with this (in fact the Seagate ST296N has only 2 buffers
build in, so the driver has to get this buffer quick from the
harddisk or it may wait another harddisks revolution on a multi
sector read).
Nevertheless I am now working to implement this layer and I will use
some more sophisticated algorithms which could be controlled for the
device dependent parts by upper layers.
This layer will become more important as other layer 3 software are
implemented (like drivers for tape streamers etc.).
layer 3 is the winchester task finding the harddisks connected to the SCSI
hostadapter, handling the logical devices, block address translation,
message passing etc.
There are a few restrictions build in here
a) only two harddisks could be managed (easy to change)
b) only one logical unit could be handled for one harddisk device
and this is LUN 0 (although the block address translation
isn't checked for now, so that great values could select other
LUN'S - this is a bug, not a feature)
c) the harddisks sector size must be 512 (as I don't know how to
handle the partition table otherwise)
d) the harddisks must have a valid partition table or they won't
be installed with this driver
and a bug/feature, that this driver will accept removable harddisks
also (unless there isn't a valid partition table) without any special
handling of harddisk changes. It is up to you, to use this feature
accordingly (don't forget to umount before changing |-).
That should be enough for now (blame me, if I have wasted your time).
Ma.D. <MDOELL@DOSUNI1.BITNET>