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.