Message ID | 646765f40901021959jd666f10t16c233a7d5dbcf4@mail.gmail.com |
---|---|
State | RFC |
Delegated to: | David Miller |
Headers | show |
On Sat, Jan 3, 2009 at 14:59, Julian Calaby <julian.calaby@gmail.com> wrote: > As such, it may be beneficial to standardize around an interface > similar to sparc32's - i.e. a structure with ->foo() calls - and make > an implementation of this that uses sparc64's single function pointer. I'm currently working on this idea and hope to have something to show in the next couple of days. Sam, if you're already working on this, don't stop, you know what you're doing much better than I do. So, even if my code never leaves my computer, I'd rather do the work and know what I did wrong than prevent you getting it right the first time.
On Sat, Jan 03, 2009 at 10:37:15PM +1100, Julian Calaby wrote: > On Sat, Jan 3, 2009 at 14:59, Julian Calaby <julian.calaby@gmail.com> wrote: > > As such, it may be beneficial to standardize around an interface > > similar to sparc32's - i.e. a structure with ->foo() calls - and make > > an implementation of this that uses sparc64's single function pointer. > > I'm currently working on this idea and hope to have something to show > in the next couple of days. > > Sam, if you're already working on this, don't stop, you know what > you're doing much better than I do. So, even if my code never leaves > my computer, I'd rather do the work and know what I did wrong than > prevent you getting it right the first time. Hi Julian. Please hack away - I look forward to see the patches. Sam -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
different. This gives me a bit more of an insight as to how these two architectures are different and how the interfaces work. As such, it may be beneficial to standardize around an interface similar to sparc32's - i.e. a structure with ->foo() calls - and make an implementation of this that uses sparc64's single function pointer. I've attached a small patch that shows what I'm thinking of - however, as my C's a little rusty, it's utterly inane and won't compile in any sensible manner - given, of course, that Gmail hasn't mangled it. Of course, a real implementation would split all the sparc{32,64}ness out into separate files, leaving a nice set of pristine prom/*.c files that reference this structure, but that isn't something you can knock up in your lunch break. diff --git a/arch/sparc/prom/tree.c b/arch/sparc/prom/tree.c index f228fe0..59f8761 100644 --- a/arch/sparc/prom/tree.c +++ b/arch/sparc/prom/tree.c @@ -20,9 +20,23 @@ extern void restore_current(void); static char promlib_buf[128]; -/* Internal version of prom_getchild that does not alter return values. */ -int __prom_getchild(int node) -{ +struct prom_ops { + int *get_child(int node); +} + +#ifdef SPARC64 + +int get_child_s64(int node) { + return p1275_cmd ("child", P1275_INOUT(1, 1), node); +} + +struct prom_ops *prom_ops = { + .get_child = get_child_s64; +} + +#else + +int get_child_s32(int node) { unsigned long flags; int cnode; @@ -34,6 +48,12 @@ int __prom_getchild(int node) return cnode; } +struct prom_ops *prom_ops = { + .get_child = get_child_s32; +} + +#endif + /* Return the child of node 'node' or zero if no this node has no * direct descendent. */ @@ -44,8 +64,8 @@ int prom_getchild(int node) if (node == -1) return 0; - cnode = __prom_getchild(node); + cnode = prom_ops->get_child(node); if (cnode == 0 || cnode == -1) return 0; return cnode;