On Wed, 2001-12-19 at 11:53, Geoffrey Espin wrote: > > > > Currently, my private pci_alloc/free_consistent() routines manage > > > FYI, this is not an isolated issue. We deal with a number of > > architectures and we've seen this problem with other arches and system > > controllers as well. A 'generic' solution would be nice and probably > > necessary at some point. 2.5 would be a good place to do it, if only > > someone would volunteer ;-) [Pete] > > Thanks for the reassurance. > > Can one include one's own arch/mips/korva/skbuff.c? > But with network.o being a monolithic blob .o instead of a .a, > seems like patching the one file is not feasible. > I tried tweaking $(HEAD) but then stumbled onto this. > How does one package such a work-around? Include a patch file in > the LSP, which gets automatically run to munge on kernel sources? If you mean MontaVista's LSP, they are built from an internal source tree, so in some sense we can do whatever we want -- at least until we implement the right solution. It's not something you want to do though because carrying patches with you does not scale well. The best approach in the long run is to do it right and push it out to the community tree asap. The problem, of course, is that if you yourself wanted to do it right, but it was going to take a while, the company you're consulting for might not want to pay for such general linux work. > Or will linux-mips.sf.net accept a patch for net/core/skbuff.c? Up the the maintainer, but it's really not the right fix so I think it's best for you or your customer to keep that patch locally. Another approach would be for you to preallocate your network buffers in your driver, attach them permanently to the rx/tx descriptors, and then copy the data from the buffer to a newly allocated skbuff, when you receive, and the other way when you transmit. There's a performance penalty there, especially for large packets, but you can encapsulate everything within your driver and you won't have to maintain a patch. Pete
