> >>>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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
