Greg KH wrote: > > Are there any other examples of drivers that isolate kernel specific > > calls to one module or file of their code to ease portability between > > different revisions of the kernel ? If not, maybe they should look at > > what we have done, it might save them some headaches in the future. > > No, that is not how Linux kernel development is done. Come on people, > do your research... To clarify: For out-of-tree 3rd party drivers, there are two or three "compatibility" packages which are used to allow a single driver source to work with many kernel versions. (I wrote one, it is used for quite a few private drivers. This method works well. See also "kcompat"). For drivers in the kernel tree, or drivers that somone would like to go into the tree, "compatibility" headers are never used. API changes are for good reasons; drivers need to be updated to follow them. When the kernel APIs change, for minor changes and sometimes even major ones, the author of the API change will often go through all the in tree drivers making the necessary changes. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
References:
- RE: [Infiniband-general] Getting an Infiniband access layer in the linux kernelWoodruff, Robert J
- Re: [Infiniband-general] Getting an Infiniband access layer in the linux kernelGreg KH
- Prev by Date: Re: [PATCH] PSX support in input/joystick/gamecon.c
- Next by Date: Re: [ACPI] acpi problem with nforce motherboards and ethernet
- Previous by thread: Re: [Infiniband-general] Getting an Infiniband access layer in the linux kernel
- Next by thread: Infiniband thread(s) and etiquette.
- Indexes:[Main][Thread]