> I tried to do that, for some reason the first patch (0/1) didn't make it > to the mailing list. Is it important to separate the #include lines > as well as the actual file moves?
In general we prefer to have separate patches for just moving things around and real new functionality. > > > > DEFINE_PER_CPU(struct pda_s, pda_percpu); > > > +EXPORT_PER_CPU_SYMBOL(pda_percpu); > > > > As mentioned the last time you posted it please use a proper accessor. > > > > I don't understand what you want. The symbol is exported so that I can > use existing macros from the tiocx code if it's built as a module. What macros are that? You should probably just turn them into normal functions unless they're performance-critical. In fact I don't like the SGI pda at all - DEFINE_PER_CPU for each individual member isn't anything less performant but much more managable. But that's not a complaint to you but the core SGI plattform people. > > With the above issues fixed it's fine to be queued up until you submit > > an actual user of this interface. > > > > I will work on providing an acceptable, meaningful, driver but it will > take a bit. Would it be feasible for this code to go in now and for > me to follow up with the driver later? What users are this? - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
