Hollis Blanchard wrote: > - you have lots of commented-out code present Patch lines : 68 : waiting for me to fix the grub_ieee1275_fb_addr stuff. 597..600 & 949..961 : I don't know how widely these functions are implemented in framebuffers, so I disabled them. 921 & 927 : Forgot those.
> - what is this "GRUB_EMBED" stuff? It's to work around the fact that sparc64 doesn't support modules. So I have to embed them inside grubof, and make them debug commands. I thought it was obvious... What may not be is that it has only a meaning for sparc64, and won't have any once module support will be added. > - I'm unclear on your distinction between "fb" and "fbprops" in file names. fb contains needed functions to make framebuffer work. fbprops only contains functions that make it easier (and less verbose) to get properties of the framebuffer devices. May be merged with fb.c, may not exist at all... I'm not sure. > In general I'd say this patch is not yet ready for merging. It's not ready for merging, as I don't even know if it builds on ppc as I said in the first mail. Moreover, I'm not sure I'll have much time to work on those next days, so I prefer posting the patch as soon as possible in case someone want to work on it. It could also help finding a common framebuffer API. I should remember to tag such mails as RFC, not as PATCH... > What is your model for framebuffer drivers in general (including across > architectures)? For example, every fb driver will provide what API, and > should that be used by common code? That common API still has to be defined... I sent some ideas in a mail some days ago. Vincent Pelletier
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
