[lkml]   [2003]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On Tue, Apr 08, 2003 at 03:46:44PM +0100, Jamie Lokier wrote:
> Alan Cox wrote:
> > > Unless you can come up with a real *reason*, I'll move it back under
> > > "deprecated" and start substituting.
> >
> > Thats fun, and the rest of us can play submit patches to substitute it
> > back.
> If Jeff's drivers are using <kcompat>, can't kcompat provide the macro
> for 2.4 and 2.5 kernels in the same way it does for 2.2 kernels?

No. Because Rusty wanted to replace a "func_call()" object with a
direct reference to a structure. Direct struct member references is the
big issue that we are trying to _avoid_, because they are the single
most painful issue to deal with, WRT source back-compat. You can ifdef
around a function quite easily, but not a direct struct member use.

To give another concrete example, I was able to take a 2.4 PCI driver
and make it work under 2.2 transparently, with a single exception: The
"driver_data" member of the new struct pci_dev. Drivers were directly
referencing that, which was a new addition in 2.4.x (really 2.3.x). So,
I created the abstraction wrappers pci_[gs]et_drvdata(), which does
nothing but a simple C assignment (or read, for _get_). The addition of
this wrapper removed the need for nasty ifdefs in the drivers for 2.2
versus 2.4, and make it possible for the kernel source to continue to be
readable, "pretty", and ifdef-free.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.044 / U:2.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site