Messages in this thread | | | Date | Mon, 03 Oct 2005 09:26:46 -0700 | From | David Brownell <> | Subject | Re: [PATCH] SPI |
| |
> >>>It'd be fine if for example your PNX controller driver worked that way > >>>internally. But other drivers shouldn't be forced to allocate kernel > >>>threads when they don't need them. > ... > FYI in brief: for PREEMPT_RT case all the interrupt handlers are working > in a separate thread each unless explicitly specified otherwise.
I'm fully aware of that; not that it matters much for folk who aren't building and deploying systems with PREEMPT_RT.
> We will definitely have less SPI busses => less kernel threads, so I > doubt there's a rationale in your opinion.
The rationale is simple: you're trying to force one implementation strategy. Needlessly forcing one strategy, even when others may be better (I already gave three examples), is a bad idea. QED. :)
> >Well "prevent" may be a bit strong, if you like hopping levels in > >the software stack. I don't; without such hopping (or without a > >separate out-of-band mechanism like device tables), I don't see > >a way to solve that problem. > > Aren't the tables you're suggesting also kinda out-of-band stuff?
I just described them that way; yes. They're not layer hopping though; they preserve the distinctions in roles and responsibilities which help keep components from interfering with each other.
One general point is that when hardware doesn't support autoconfiguration, something out-of-band is required to plug that hole. In this case, those tables can be segmented to handle SPI devices on both mainboards and add-on boards. Ditto for SPI controllers, but that mostly matters for developer tools like parport adapters.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |