Adaptec AAC raid support

Charles Swiger cswiger at
Sat Mar 19 15:42:48 PST 2005

On Mar 19, 2005, at 6:02 PM, Ted Mittelstaedt wrote:
>> I don't think Adaptec dictated terms to Intel vis-a-vis the i860 chips
>> used for hardware parity computation on some of their RAID cards, for
>> example.  I don't think Adaptec dictated terms to Dell vis-a-vis the
>> PERC 4 series, either.
> Whaat?  Dell?  The PERC 4 is an AMI device, Dell doesen't make chipsets
> they are an assembler.  The amr driver supports it and is open, so
> obviously there was never an NDA there.

Maybe I was thinking of the PERC 3, then-- this one:

aac0 at pci2:2:1:  class=0x010400 card=0x00d11028 chip=0x00021028 rev=0x01 
     vendor   = 'Dell Computer Corporation'
     device   = 'PowerEdge 3/Di Expandable RAID Controller'
     class    = mass storage
     subclass = RAID
[ ... ]
none1 at pci3:4:0: class=0x010000 card=0x00c51028 chip=0x00c59005 rev=0x01 
     vendor   = 'Adaptec Inc'
     device   = 'RAID Subsystem HBA'
     class    = mass storage
     subclass = SCSI
none2 at pci3:4:1: class=0x010000 card=0x00c51028 chip=0x00c59005 rev=0x01 
     vendor   = 'Adaptec Inc'
     device   = 'RAID Subsystem HBA'
     class    = mass storage
     subclass = SCSI

> And as for the i860, there's tons of programming docs on the Internet 
> out
> there for it, once again, it's already open.

You've failed to address the point.  Do you claim that Adaptec is in a 
position to ignore an NDA they have with a company like Intel or Dell?

>>>> But the hardware vendors aren't obligated to meet your demands,
>>> This is also bullcrap.  The hardware vendors are obligated to support
>>> THEIR customers who have bought product from them.  Some of those
>>> customers want to run OpenBSD.  Therefore the hardware vendors are
>>> obligated to get off their fat asses and work with the OpenBSD people
>>> regardless of how they may personally like or dislike them.
>> Hardware vendors publish software compatibility lists.  They have an
>> obligation to support their products on the systems they claim to
>> support.  They have no obligation to support their products when used
>> on systems they do not claim to support.
> There is a difference between legally obligated and morally obligated.
> You were originally speaking on moral obligation, then switched to 
> legal
> obligations.

I never made a particular distinction as to the nature of the 
Your claim that I switched positions is dishonest and deserves 

> Naturally, if Adaptec claims support where none exists, that is fraud.
> But if Adaptec customers want to use their products on OpenBSD, that is
> still an obligation, while it may not be a legal one, it is definitely 
> a
> moral one.  Or are you arguing in favor of scrapping the customer is
> always right idea?

You've created this strawman argument, answer it yourself.

> All the people arguing with Theo against pulling AAC support from
> OpenBSD's generic kernel are doing so based on a moral obligation that 
> they feel
> Theo has to his users, you cannot argue that he has a moral obligation
> and Adaptec does not.

I'm not interested in sophistry about Theo's "moral obligations" to 
OpenBSD users.

The basis for my position is simply one of "does the system work better 
after the change"?  The AAC driver now in OpenBSD evidently works well 
enough that thousands of OpenBSD users would be critically affected by 
its removal.  I'm perfectly willing to disagree with people who feel 
that breaking OpenBSD is a constructive action, and all the egocentric 
posturing does nothing to hide the nature of this change.  Quite the 
contrary, in fact.

I would never choose to do business either with Theo or with you, to be 
very honest.  I don't think I could rely on you to act sensibly even in 
your own best interest, much less be reliable acting together in a 
mutually beneficial partnership.

There's not much else I can say, and I'm not really interested in 
arguing with other people over their opinions-- you can believe 
anything you want to, even if it fails a reality check-- so I'll stop 


More information about the freebsd-questions mailing list