> From: sabell@ARGONET.CO.UK (Stuart Bell )
> To: port-arm32@NetBSD.ORG
> 
> A couple of comments on the kind of critical analysis that I guess most of us
> would make after 2 unproductive days. They come from a UNIX 'near-virgin' who
> only last week amazed himself by getting RiscBSD up and running:

I am very happy for you.

I assume from what you have said that you followed the installation
instructions and had absolutely no problems.

Did you install 1.1 beta or 1.2 beta?

> [snip]
> 
>> I tried to use my Acorn SCSI card with my HP C3325A SCSI drive.
>> This drive was formatted 400 MB to RISC OS.
>>
>> I am very persistant, and I this refuse to install it to an IDE drive
>> first as I did the first time I installed RiscBSD. As a matter of 
>> fact, I do not even have a suitable IDE drive for RiscBSD. The
>> 210 MB I have is my boot disc, and too small for RiscBSD anyway.
> 
> But you could put a boot partition on it, and put most other RiscBSD stuff on
> the SCSI drive? Surely the nature of beta releases is that we may have to
> compromise a little on our ideal solutions, in order to get things running?

Yes, I could do that, but I was not able to boot RiscBSD normally, so
that wouldn't have helped me.

The 1.2 beta was supposed to handle SCSI as well as IDE as far as I
have been able to deduct from the postings to this list.

So, I assumed that was true and started the task. It seems to
me that is true, but that there may be some bugs in this code.

The first time I installed RiscBSD 1.1 beta, I had to remove my Acorn SCSI
card from the Risc PC in order to boot at all. That problem seems
to have been fixed, so things are starting to get better.

But, I cannot agree with what you say about beta releases.
A beta release is a finished product that still may have lots
of bugs. What you are talking about is what I would call an
alpha release.

An alpha release is an unfinished product that is released in order
to get feedback about the product and problems that may be
inherant in the code. This feedback is then used to figure out
which changes needs to be done before a final release.

The version of RiscBSD I tried to install is a beta release. In
other words, it should only have bugs like the one I probably found.

Another thing that springs to my mind that needs to be documented
is which configurations the release has been tested on.

This is very important to know so that people, like me, can
see that: "OK, my configuration has not been tested." This way
people will know that there may be problems lying around, and
perhaps decide to reconfigure their computer to one of the
tested configurations first. If that works, they could then
try their normal configuration afterwords.

> [snip]
> 
> >But, now another problem turned out. It seems that the filecore
> >partition has been formatted with 64 sectors/track and
> >8 tracks/cylinder, but the disc is physically 127/9.
> 
> >Unfortunately, bb_riscbsd is using the logical data that filecore
> >reports, and RiscBSD itself is using the physical.
> 
> >How can I possibly find a number of cylinders that gives the
> >same number of blocks for these two different ways of splitting
> >the cylinders in the area between 400 and 500 MB?
> 
> The fundamental problem seems to be the use of a SCSI drive to boot RiscBSD.
> If this is the case, it needs addressing, but in the final analysis hardly
> justifies the opening paragraphs of the original posting.

I believe that the same problem would have occured with a larger than
2GB IDE drive just as well as with my larger than 2GB SCSI drive.

Also, it has been found that this problem is unsolvable. There
is no common set of cylinders in that area. They will probably
match around cylinder 1 000 000 (physical).

It is quite normal and fully accepted to use a different
logical configuration than what the disc physically is. The
drive will do the mapping from logical to physical.

UNIX, on the other hand, needs to have the physical configuration
as it uses this to schedule the sequence it reads the disk blocks.
This is done in order to achieve the highest possible disk
performance. It does this by e.g. making sure that all requested
reads on the current cylinder is done in one go, even if the
sequence in which the blocks were requested is different.

Therefore, in order to have a high disk performance, UNIX's needs
to know the physical layout of the disc, whereas RISC OS and
e.g. MS-DOS does not.

> [snip]
> 
> >2) My HP drive is larger than 2GB, how will that work with RiscBSD
> >on a RISC OS 3.6 computer? What about 4GB drives?
> 
> I'm using a 1.6Gb drive with 3.6 - no problems. Why should 2Gb or 4Gb be
> significant under 3.6?

This is because RISC OS 3 v. 3.6 only handles 2048 MB drives.
Your 1.6GB drive is therefore fully supported in v. 3.6.

My SCSI drive is actually 2069 MB, i.e. larger than v. 3.6 will handle.

The reason I am asking about 4GB drives is that that is the next
normal step if you want more than 2GB.

> Clearly, Thomas had a major problem with a SCSI-based installation. But I
> don't think that in the cool light of day it justifies his rather protracted
> critique of the priorities of the RiscBSD project. The fact that he hit a bug
> - possibly a significant bug - doesn't necessarily outweigh the fact that
> installation, while it could be better documented and should encourage and
> explain the use of a CD and UnixFS, can be achieved on fairly 'standard' Risc
> PC systems by someone who had never ever used a Unix system in his life
> before.               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(First of all, my name is Kjetil Thomassen. My email address is
composed primarily of my last name, and not the first name as is
more common. I am just pointing this out. We all make mistakes,
so I am not offended.)

But, that is exactly my point. The installation procedure is pretty
good when it comes to standard configurations, but I believe that
most people who wants to contribute and not just use it, will have
a non-standard configuration. In order to get these people up
and running, the installation issue for non-standard configurations
needs to be prioritized.

If I had been made aware of the fact that unixfs uses FileCore,
before I installed RiscBSD the first time, I could now have
used my time to e.g. re-compile sets instead of messing around with
the installation.

Also, this problem was not directly SCSI-related.

I was not able to install to the RAM disk. I do not think that this
has anything to do with the fact that I intended to use SCSI. I never
got to the stage where I was to specify whether to use SCSI, IDE or
ST-506. It may of course be related to the fact that I have an Acorn
SCSI card installed, but that is irrelevant. RiscBSD should ignore
any equipment that is not supported, and my Acorn card is supported.

The first time I installed RiscBSD I had to install it to an IDE
drive, and then copy the filesystem over to my SCSI drive. When
that was done, everything worked fine. I think that this intermediate
step should be unnecessary, and I do not think that that would be
too much work to accomplish.

> I hope that would-be users of RiscBSD who are wondering about taking the
> plunge will not be put off by Thomas' problems. With a more basic
> configuration, and using an IDE drive, there is no need for there to be any
> insurmountable problems, especially if a CD ROM drive allows you NOT to have
> to use a pile of floppies. My success no more makes the installation process
> perfect anymore than Thomas' difficulties means that RiscBSD is in crisis! 
> 
> Sorry for the rather polemic rather than technical nature of this posting, but
> I wouldn't want potential users to be put off by Thomas' saga. Nor would I
> want the RiscBSD team to get a persecution complex!

I completely agree with you, and I am sorry if my email was interpreted
that way. It was not my intention to put people off, nor to offend.

It is just that I am a bit frustrated that I cannot install RiscBSD
to a supported device directly.

Also, this is a problem that has been there from the start.
Support for new devices has been added to RiscBSD, but support
has not been added for them in the installation software.

And that is really frustrating. What would you have said, e.g.
if you were told that this new car engine will work in your car,
but that you have to install it in another car first, and then
take it back to your car?

I admit that this analogy is not quite right, but it gives the
idea of what I am talking about.

I also believe that support for new devices should not be done
in beta releases until it is completely finished. It is quite
ok to do this in alpha releases, but if the device is not
fully supported it should not be included as standard in a
beta release. By fully supported I mean that it can be used
in all sub-parts of the OS, including installation. I do not
mean that it should be optimized or perfect in all situation,
but that it should work.

In other words: The first step in my opinion is to make sure
all devices that are added are added in all code. This code
need not be optimized, but it should work.

Then, the second step is to:
1) Add new devices, or
2) Optimize the ones that are supported.

Personally, I think that at this stage we need to finish the
ones that are partly supported and then optimize them before
we add new devices. There is one exception to this rule, and
that is the 16-bit sound upgrade. This should be added ASAP
as this is standard in the new Risc PC's and most people have
added this to their old ones.

I know that the kernel team are doing the best they can, but
they are overloaded with work, and the only way to get the
load off them is to make sure that everyone who wants to
contribute are able to install RiscBSD, that the source
code is available, and that proper documentation exist.

Also, there should be a list on the W3 documenting the work
that still needs to be done. This list should be updated
continuously and also contain information about who is working
on what.

I hope that this information clearifies some of the issues
in my previous email.

I think that RiscBSD is great, but that the development
should be a bit more organized. Also, I think that it
is important to get more people involved with this.

In the time to come, I *will* be spending time on RiscBSD
as I think that this is an operating system of the future
for Risc PC owners.

Kjetil B.