[lkml]   [2001]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Making a module 2.4 compatible
On Mon, 25 Jun 2001, Timur Tabi wrote:

> ** Reply to message from James Lamanna <> on Sat, 23
> Jun 2001 22:10:58 -0700
> > It would be nice to have it working under 2.4, so is there someplace
> > that outlines some of the major things that would have changed so I can
> > update the module accordingly?
> Unfortunately, no. But if it turns out I'm wrong, please let me know what you
> find.

As a start:

wait_queue_head_t Now defined.
You can do '#if !defined(...)` and make code changes backwards compatible.

Macro, THIS_MODULE is now the first member of struct file_operations.

Include <linux/init.h> __init data type for one-time initialization code
or data.
This is new, hense not backwards compatible.

Explicit initialization of spin-locks, SPIN_LOCK_UNLOCKED and/or
spin_lock_init(spinlock_t *);
If you fix this, it's backwards compatible.

ioremap() and friends is now required even for low memory stuff.
You can no longer access this with a simple pointer, you must
use readl()/writel(), etc., for proper defererence. If you fix
this, it's backwards compatible.

These changes should get your module to compile (or nearly so).

Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

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 12:55    [W:0.063 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site