>The problem with that approach is that the "s" versions must also take
>care of byte swapping (or rather _not_ byteswapping while the non-"s"
>do the byteswapping).
>
>So we would need to have raw_{in,out}{b,w,l}. Currently, it's not
>possible to implement {in,out}s{b,w,l} in an efficient way because of
>that.
>
>Then we would also need to expose the io_barrier for CPUs like PPC
>
>etc...
>
>I tend to think that makes us expose too much CPU-specific things, which
>is why I'd rather have the {read,write}s{b,w,l} versions provided by the
>arch so those can be done "the right way" in the arch code, and drivers
>not care about some of the gory details.
Ok, thinking more about it, I think finally that you are right. Since
we also have the "_p" crap entering the dance, that would really make
to much functions to abstract. However, if we decide to go the way
you describe, the we should probably also provide the raw_{in,out}*
ones.
Ben.
-
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/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:19 EST