Re: boot loader question

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

lybsd.org> <20050405084741.GA3491@xxxxxxxxxxxxxxxxx>
In-Reply-To: <20050405084741.GA3491@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 54
Message-ID: <425262a7$0$719$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.82.16
X-Trace: 1112695464 crater_reader.dragonflybsd.org 719 218.253.82.16
Xref: crater_reader.dragonflybsd.org dragonfly.users:2726

Joerg Sonnenberger wrote:
> On Tue, Apr 05, 2005 at 04:32:28PM +0800, Bill Hacker wrote:

>>decode that
>>in a gate array and save a lot of time and code execution.
> 
> 
> But it would also increase the costs of the bus protocol dramatically.

Not at all.  Decrease it.

> Keep in mind that PCI interrupts are additive (level triggered?),

Open collector/wired OR   .. or the functional equivalent.
not too different from S-100 or Q-bus.
(Not that there is a lot of difference at current bus speeds!)

Nor does it matter if they were bit-patterns on a serial optical bus
or parallel copper traces on a MB or conductors on the chip.

The point is that we have provided too few *unique* states.

We map memory and I/O to the architecture - 16, 32, 64 bit
- yet allow only a miniscule fraction of that for interrupts,
requiring 'sharing' which in turn requires an inquiry process
to sort *which* of the shared devices is to be serviced.

We could have had 64 unique IRQ's way back then, and 256 unique IRQ's 
now, for next to no cost.
32K hardware IRQ's is probably overkill - then again, IBM PC1 seemed to 
think 8 were too many.

> read as long as any device has the interrupt triggered,
> the system can handle it.

. ..with a good deal of software,  i.e. sense INT is high, scan for which 
device(s), did/are doing that, chat with them,
lookup what is needed to service them, clear the IRQ ...and other things.

Too much of it is in software, when fractional cents worth of silicon 
and copper could have made the job easier by providing more info up front.

> It's the simplest and most efficient way to avoid
> races without additional bus cycles, which can often be even more
> expensive.
>

The need for prioritization, queueing, avoiding races and such doesn't 
magically disappear, but having more unique info from the hardware at 
first instance can make management simpler and faster.

> Joerg

But this is not a DragonFly issue, so I will shut up about it.   ;-)