On Feb 7,  9:06pm, Rick Kelly wrote:
> Subject: Re: NetBSD i386 bounce-buffer non-feature [was Re: Memory leak?]
> Jonathan Stone said:
>
> >A data point: I'm the NetBSD/pmax chief port-slave.  Some colleagues
> >here (e.g., CS faculty) have recently asked me about free Unices with
> >more solid networking than Linux.  I end up advising them that they
> >should use FreeBSD, because NetBSD/i386 just isn't *REAL*, because to
> >the best of my knowledge NetBSD/i386 doesn't support more than 16
> >Mbytes with ISA cards like an aha1542.  And I end up reassuring these
> >people that the two systems aren't really _that_ different, at least
> >on x86 hardware.
>
> I don't think that an OS should use kludges to make up for underlying
> hardware limits, at least not on cheap, Intel commodity hardware.
>
> >I find this embarrassing for the project.  It's something that has
> >given great marketing mileage to (for example).  To the point where
> >those who _consider_ alternatives to Linux think FreeBSD is all there
> >is.
>
> I take a certain interest in news postings that describe the bounce
> buffer support in FreeBSD and Linux as performance killers.
>
> >I think, respectfully, that this needs to be fixed.  Yesterday.
> >(Even that  may be too late.)   And it's gone on long enough
> >that, IMHO, it's time to ask the relevant portmaster and Core members:
> >
> >	*Why is this still broken?*
>
> The hardware is broken, not the OS.

This suggests that the fix should be in the i386 port machine-dependant code.
Presumably it is felt that the bounce-buffers would have to be implementented
in machine-independant code otherwise I can't see any reason not to do them. I
would have thought it would be easy enough for the i386 port to reserve a block
of physical memory at boot time which is then used for a DMA bounce buffer. The
only things which would need changing this way are specific to the port or
drivers. In other words it isn't a job for the core, but for the i386 port
maintainer. Am I missing something?

Cheers

Rob Black

--