Hi Sean,
> While I understand what you want Theo lets not remove
> the support for stuff that currently works.
Er, well, that is not the whole story...
When you first install such a board (in my case 2410SA),
it first appears to read and write data from and to disk.
But after some weeks or so, be prepared to put up with
the kernel locking up. See my previous posts on the subject,
and i have not been the only one suffering from that.
What is more, you probably want RAID management when you buy
a RAID card (things like being able to find out soon when a disk
died and the controller switched to the spare). You almost
certainly do not want daily attended reboots in order to find
out from the RAID BIOS whether all your disks are still alive.
> I just spent $349 on a Adaptec RAID card for my home server
So did i, and it's not even a home server. When we bought it,
- we read "RAID management features" in the Adaptec ads
- and we read "driver available, management worked upon"
in the OpenBSD docs & resources.
Would you have bought it knowing that
- RAID management will never arrive
- developers cannot sort out intricate firmware or driver
issues due to lack of hardware documentation?
I would have bought hardware from a different vendor
had i known all that beforehand.
In case Adaptec fails to provide full docs, in my humble
opinion Theo *must* at least remove the boards from the list
of supported hardware. Otherwise, he will mislead OpenBSD users.
I would even agree it is *better* to remove aac(4) from the kernel
source tree if
- it is an incomplete driver
- and hope that it can ever be completed is marginal.
You know, when i buy new hardware, i grep the source tree
beforehand and have a look what the driver sources say
about the stuff. I'm certainly not the only one doing
so. Thus, having incomplete drivers in the source tree
tends to mislead people into believing the stuff is working.
Of course, you could put up large sign posts yelling
/*** THIS STUFF DOESN'T WORK ***/
all over the place in the sources. But is that really
a good idea? This is not what i understand by "functional
and secure by default". On top of that, people will keep
asking confused questions about it: Why is there a driver
in the kernel if it is not supported? Why isn't it listed
as supported if there is a driver that works for me? What
part of your kernel is proken, precisely? You are sure
nothing else is broken by that code, too (i'm seeing kind
of a strange problem just 'round the corner)? Why do you
put code into the kernel if it is broken?
Ok, maybe you do really want to use a RAID board with a
quite possibly buggy firmware and a clearly incomplete driver -
i'm not so sure i want to use such a thing, even having spent
rather a large amount of money on it, compared to my budget.
After all, RAID is about reliability, isn't it? If i *know*
the driver is incomplete and the board is not fully reliable,
wouldn't i be better off just kicking the board out and using
the same disks as a software raid?
Anyway, let's assume you do really want to use it.
Then why not copy the driver sources into your source tree
and roll your own kernel? After that, if you break your
kernel, you will of course be on your own. But what use
will "support" by the kernel hackers be if they don't have
the information they need for properly supporting you?
The only effect i manage to see is OpenBSD tech folks
wasting their time on a struggle they cannot win...
> and if the support is removed I will be very upset.
> The drive is written. Leave it alone.
I have lost *days* trying to debug my server, including Dec 25
and Dec 26, 2004. You will understand i was close to getting
upset, too. But *not* against Theo and his crew who were
really helpful.
> Let it be up to the end user to pick which card they want
> to buy. You can not go back and undone support for something
> you have listed!
Not even if it turns out to be buggy and incomplete beyond
repair?
Yours respectfully,
Ingo Schwarze
--
Ingo Schwarze <schwarze@usta.de>
System administration, University of Karlsruhe student organisation
http://www.usta.de/
|