Re: config_activate()/config_deactivate() ?

[David Young <dyoung%pobox.com@localhost>]

On Mon, Apr 06, 2009 at 12:51:42AM +0200, Martin Husemann wrote:
> On Sun, Apr 05, 2009 at 05:08:17PM -0500, David Young wrote:
> > Do you think that it will be a great deal slower on SPARC?
> 
> No, and I don't worry about sparc or pcmcia, but modern machines and
> pci-x or whatever they have next year.

I am very interested in what you have to say about the matter.  Please,
be more explicit about your concerns.  I'm having to read a lot between
the lines. :-)

Are you concerned that I/O cycles will get a lot shorter, but CPU cycles
will not?  So, while I/O overhead may dominate bus_space(9) overhead,
today, it may not in the future?  I believe that will happen, however, I
am not sure that it matters very much.

> However, I'm not yet convinced that this solution is the right thing to
> do - even if it clearly saves a lot of hard to debug/test work.

Calling config_deactivate() seems like too little, too late: card
ejection is not synchronous with interrupts, ioctl()s, et cetera, so the
kernel may have already begun a sequence of bus_space(9) reads/writes
when config_deactivate() is called.  Some systems will trap the bad
accesses.

I think that we ought to both invalidate the bus_space_tag_t and handle
such fault conditions (NMI, MCHK, etc.) as accessing a detached card
will cause.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933