> > >>>>> On Tue, 29 Jul 2003 14:15:20 -0700, Christopher Wedgwood <cw@sgi.com> said: > > Christopher> No --- because there are no other users... the code > Christopher> was almost certainly written a long time ago to solve > Christopher> an SN specific purpose and has been carried around in > Christopher> the form I presented. > > Christopher> I fully admit that in a general sense this code isn't > Christopher> workable but I think perhaps the concept of some kind > Christopher> of UC allocator might be. I've gotten a little confused about this thread. A general purpose UC allocator is a lot more than is needed by SGI. All we need is a way to walk the memmap & locate entries with a specific set of atributes (we need UC but other users may have different requirements). I think someone (david?) proposed an interface that would take a mask/attribute pair. This is all that is needed. It seems general enough so that other code may use it too. Would this be acceptible?? > I'm sorry, but that's _exactly_ the problem. You are pushing an > SN2-specific hacks into the ia64 kernel and you seem to think that's > OK. I don't want the ia64 kernel to turn into a collection of > vendor-specific hacks (whether from HP, Intel, SGI, or anyone else). > Yes, doing clean, general and efficient APIs is hard, requires > thinking, talking to others, etc., but it's the only way to get a > kernel that's maintainable. If you only care about > efi_memmap_walk_uc() for SN2, that's fine by me, but in that case it > will stay in the SN2 tree. If you want something in the normal ia64 > kernel, please propose an API (and patch) that actually makes sense > beyond SN2. > > --david -- Thanks Jack Steiner (651-683-5302) (vnet 233-5302) steiner@sgi.com - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Jul 29 18:06:13 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:16 EST