Re: Generic Kernel API

> On Wednesday 09 November 2005 15:23, Charles Swiger wrote:
> 
> > Of course, it's easier to say such things then to write the code, but
> > Apple has achieved pretty good results from the IOKit. 
> 
> I'm really out of my depth here, but the one thing Apple seems to have 
> accomplished with IOKit is abysmal performance.  When it no longer takes me 
> four times longer to backup an iMac than a much slower FreeBSD machine with 
> an older drive, I'll be more impressed with their technology.
> -- 
> Kirk Strauser

When Apple was working on the second generation Airport wireless access
points, I and a cow-orker ended up taking a trip to the Apple campus to
help debug a problem (they were using VxWorks). In some cases it was
possible to crash the access point, though you had to flood it with a
lot of traffic to do it. The engineer working on the device had a nice
Apple laptop in his office which he was using as a traffic monitor and
generator to debug the issue. I arrived armed with my trusty Sony VAIO
Picturebook, which uses a Transmeta Crusoe TM5600 667Mhz CPU. I'm pretty
sure the Apple laptop had way more CPU horsepower than this.

Anyway, the engineer there had been trying to use his laptop to generate
a flood of traffic to crash the AP (reproducing a crash is the
first step to fixing it), but wasn't able to do it very reliably. For
the most part, the AP stubbornly refused to die. So I took out my laptop
(with FreeBSD 5.2.1, of all things), plugged in my 3Com xl(4) ethernet
card, and ran ttcp to generate a stream of UDP traffic. I was able to
crash the AP almost right away.

Now, I realize that IOKit looks really neat on paper and conceptually
has lots of nice advantages, but in practice I think it has performance
problems. I'm sure you can get a Mac to saturate a 100Mbps ethernet
link with a TCP stream test, but with that test you'll only end up
producing about 8000 frames/second, which really doesn't need that much
CPU power. It's when you need to generate 80000 or 100000 frames/second
that you start running into problems.

Also, while code re-use seems like a laudable goal, you have to be
careful how you do it. I don't think there's much difference in the
amount of code re-use between an IOKit driver and a standard BSD ifnet
network driver. Take a look any any given driver, and while the code
may appear to share many structural similarities, it's actually quite
different, because the underlying hardware is different. You can
abstract away certain machine specific things, like DMA and register
access (which we do with busdma and bus_space), but you can't easily
create common code for DMA descriptor setup, interrupt handling,
chip initialization and so on, because all each chip has different
descriptor formats, and interrupt signalling/masking mechanisms
and initialization procedures. You have to avoid falling into the
trap of thinking you can generalize these things just because you may
have found one or two cards/chipsets that look kind of the same.

There's another issue, which I think has already become a problem with
Windows, which is that there's such a thing as insulating driver developers
too much from the underlying OS. As was said earlier in this thread,
network and storage are probably the most critical types of driver classes.
The more network cards and disk controllers you support, the better.
For network adapters, Microsoft has the NDIS miniport API. For disks,
they have the storport and scsiport miniport APIs. Behind the scenes,
these miniport libraries all use the Windows Driver Model (WDM) which
encompasses such things as the I/O manager, IRPs and the Plug&Play
manager, but those APIs are very complicated and easy to screw up
(IRPs especially), so Microsoft recommends using the NDIS, storport
or scsiport APIs instead. In fact, I think you're forbidden to stray
outside the scsiport/storport API at all if you want to get your driver
WHQL certified and signed (the rules are a little less strict with NDIS
because you need to use WDM for things like USB network adapters).

That's fine and all, but I think what you end up with is developers
who know how to use the particular miniport API that concerns them,
but who _don't_ know much about the underlying OS in general, which I
think is a _bad_ thing. You _want_ to know how the underlying OS works,
because that can help you understand why the miniport library layered
on top of the other OS facilities does what it does. You can probably
get by without that understanding, but if you did, I wouldn't by a
NIC with a driver you wrote. :)

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================