Hello Thomas! > No it's not. Major code abstractions behind preprocessor tokens are > terrible to maintain. Hmm, don't get me wrong but I'm not sure if the changes were really checked in detail. At first sight it might look like I'm adding tons of new macro ridden code in those header files replacing cleaner code. While actually that's just how the I/O version currently is, copied and white space cleaned (as it was requested) plus comment style matched with sys. The only new thing which hides the mentioned abstraction a little more is FB_MEM, which replaced __iomem. But that's a tradeoff to be able to use the same source for system as well. Or the concern is that now system memory specific code might get mixed in there by mistake? It was not planned as the final version, the current maintainer asked for addressing some pre-existing quality issues with further patches but otherwise accepted the taken approach. > It's also technically not possible to switch between system and I/O > memory at will. These are very different things. Yes, there are architectures where these two don't mix at all, I'm aware of that. I need that on x86 only (for old hw), and there it seems doable. Depending on the resolution either the aperture or the defio memory is mapped. If the framebuffer is not remapped after a mode change that's an application bug. Otherwise it's harmless as both are always there and don't change. I'd better like to find out problems sooner than later, so if you or anyone else could share any concerns that'd be really helpful! > If you want that pixel-reversing feature in sys_ helpers, please > implement it there. Actually that's what I did first. Then did it once more by adapting the I/O version as that gave me more confidence that it'll work exactly the same and there's less room for error.
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
