Re: [RFC] remove bus_memio.h and bus_pio.h
From: Doug Rabson (dfr_at_nlsystems.com)
Date: 05/26/05
- Previous message: Doug Rabson: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- In reply to: Marcel Moolenaar: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- Next in thread: Scott Long: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: freebsd-arch@freebsd.org Date: Thu, 26 May 2005 09:33:47 +0100
On Wednesday 25 May 2005 18:40, Marcel Moolenaar wrote:
> On May 25, 2005, at 10:19 AM, M. Warner Losh wrote:
> > Short answer:
> >
> > Great idea.
>
> Seconded.
Thirded.
>
> > Longer, more detailed answer.
> >
> > The original idea was to provide a hint to busspace that this
> > driver only ever used a certain subset of the available mappings so
> > it should assume that subset and agressively optimize the code.
>
> It has also worked against, well, me in the past in that I couldn't
> figure out why a driver simply didn't want to work with memio while
> it worked perfectly with pio. Then I spotted the bus_pio.h header at
> the top and cursed, cursed, cursed.
>
> I'm all for performance tuning, but the newbus optimization is just
> too weird for its own good this way.
Hey, don't blame this on newbus - it predates newbus by quite a bit. I
seem to remember that this came in with the first import of CAM so you
can blame Justin :-)
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Doug Rabson: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- In reply to: Marcel Moolenaar: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- Next in thread: Scott Long: "Re: [RFC] remove bus_memio.h and bus_pio.h"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: [RFC] remove bus_memio.h and bus_pio.h
... On Wednesday 25 May 2005 18:40, Marcel Moolenaar wrote: ... >> driver
only ever used a certain subset of the available mappings so ... don't blame this on newbus
- it predates newbus by quite a bit. ... can blame Justin :-) ... (freebsd-arch) - Re: newbus integration of MOD_QUIESCE
... The only way to fix it is to do a three-phase commit and that would ... newbus
cannot solve that problem for us either. ... >method if possible to reduce the load on driver
writers. ... discovering new things before you do the unload. ... (freebsd-arch) - Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE!
... information from the OF in the probe routine (should be probably attach ...
: child to the newbus. ... in the NULL devclass to every driver registered
in the system. ... (freebsd-current) - Re: Devd event from GEOM?
... >that have no physical representation and so aren't visible to newbus. ...
devfs events on the other hand tells us that something can be ... where we need to do more
than respond to newbus by loading the driver. ... the type of device to devd to save some
rather complex code in userland. ... (freebsd-current)