SET_MODULE_OWNER?

I thought it was completely useless, hence deprecated.

Anyone have any reason to defend it?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

It's used in the net drivers to set their owner. One could argue whether it makes sense to use a macro for it or not, but as most drivers converted to new-style refcounting use it I don't see any reason to deprecated it.

It's used to allow source compatibility with all kernels, old or new.

Thus it is in active use, and should not be removed.

Jeff

In message <[email protected]> you write:

Inside individual drivers, or a set of compat macros, it makes sense. But as a general module.h primitive it doesn't.

Imagine a structure adds an owner field in 2.5. This macro doesn't help you, you need a specific compat macro for that struct.

ie. AFAICT it only buys you 2.2 compatibility, and even then only if you #define it at the top of your driver.

I still don't understand: please demonstrate a use in existing source. Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

I do agree it only does something which we do manually with a lot of the other members, however i'm not quite sure wether the compatibility thing still holds since a number of drivers have a lot of 2.5 specific stuff (e.g. pci-dma api changes). Regardless, here is a typical use in a netdriver.

	/* dev and dev->priv zeroed in alloc_etherdev */
	dev = alloc_etherdev (sizeof (*tp));
	if (dev == NULL) {
		printk (KERN_ERR PFX "%s: Unable to alloc new net device\n", pdev->slot_name);
		return -ENOMEM;
	}
	SET_MODULE_OWNER(dev);
	tp = dev->priv;
	
	/* followed by ... */
	dev->foo = __foo;
	dev->bar = __bar;


	Zwane

--
function.linuxpower.ca

In message <Pine.LNX.4.50.0304072212310.21025-100000@montezuma.mastecende.com> you write:

ev->slot_name);

I don't understand how that helps compatibility over:

	dev->owner = THIS_MODULE;

Both will:
1) Work on 2.4 and 2.5
2) Break on 2.2.

Confused,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Wrong.

SET_MODULE_OWNER works in 2.2 _and earlier_... given some compat glue in a "#include <kcompat>" macros.

You may take a look at "kcompat" for further examples. http://sf.net/projects/gkernel/ I provide an example of how to get a net driver from 2.4 running under 2.2, such that the 2.4 driver -appears- to be completely free of compatibility glue.

The only sticking points in such glue are when structure members are directly exposed in the source code. That cannot be worked around with cpp magic. This is why SET_MODULE_OWNER exists, this is why pci_{get,set}_drvdata() exist, and so on.

Jeff

In message <[email protected]> you write:

Interesting. How is this related to the older linux/compatmac.h? Have you thought of actually integrating a 2.4<->2.6 version once 2.6.0 is out?

Thanks for the pointer!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

It's not related at all to compatmac.h, though there are no doubt duplicate definitions in there. This is mainly my own code, plus tytso's (serial.c), plus Donald Becker's.

Oh, I would love to have such items in there... I take patches, and no need to wait for 2.6 either :)

Jeff

no, SET_MODULE_OWNER is quite intentionally independent of the struct. It only requires a consisnent naming in the source, between structures that may use the macro.

That's a feature.

no, farther back than that, to infinity and beyond :) The idea of the macro is that on earlier kernels, it is simply a no-op, and module refcounting is handled by other means.

demonstrate? grep for it. It's used quite a bit. Removal of SET_MODULE_OWNER looks to me to be pointless churn for negative gain. If if you wish to pointedly ignore the old-source compatibility angle, it is a nice convenience macro.

Jeff

In message <[email protected]> you write:

Crap. Since hch removed the other module ops, if your module does its own refcount THAT won't compile in 2.5.

This is complete crap. It's an obfuscation macro, with no backwards compatibility capabilities as currently implemented.

Christoph went through and substituted try_inc_mod_count to try_module_get, for no gain, and broke backwards compatibility.

Unlike that, substituting dev->owner = THIS_MODULE; has no backwards compatibility loss, and it removes a confusing and pointless macro which *never* had a point.

Unless you can come up with a real *reason*, I'll move it back under "deprecated" and start substituting.

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

You can still implement try_module_get and module_put on older kernels. Jeff mostly cares about net drivers anyway that use neither :)

Its an abstraction macro.

Thats fun, and the rest of us can play submit patches to substitute it back.

This is not how to work with people

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?

-- Jamie

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.

Jeff

I've done similar things myself. My drivers, including network and char devices, work on all kernels from 2.0 to 2.4 using similar kcompat-like macros. I've not extended any to work with 2.5, though.

If you want to write drivers that work on 2.4 and 2.2 kernels, that's
easy: #include <kcompat.h> or whatever you use, and call SET_MODULE_OWNER in your drivers.

However, if you insist on using drivers from the 2.4 kernel tree on 2.2 kernels, that's a different matter, and you have a point.

For 3rd party drivers that I've written, I take the first approach and write code that very nearly conforms to 2.4 style except when it is not possible for that to be back compatible. This occurs in certain file operations (2.0 has different function prototypes), in mapping device memory to user space (change from vma->vm_offset to ->vm_pgoff, PCI configuration (lots of changes in 2.1.93 :) and a few other things.

It is all very well to insist that SET_MODULE_OWNER() remains so you can take 2.4 drivers and easily compile them for 2.2... but why is that the benchmark? I can't take 2.4 drivers and do that, because I want to support 2.0 as well, so I bite the bullet and make the necessary changes for broader compatibility.

So.. back to a point. Is 2.2 compilability (with the help of kcompat) one of the goals to aim for in 2.5 drivers generally? Or is this specifically meant for the network drivers which you support?

Cheers,
-- Jamie

You can do 2.0 compat with kcompat. Just needs a couple more compat macros in kcompat tarball. I grant you that net drivers are much more resilient across kernel versions, and are easier to make portable across the various kernel API changes -- precisely because we've managed to keep the core interfaces fairly stable, logic- and locking-wise. SET_MODULE_OWNER is just one more piece of this conscious effort.

In general, the mainline kernel has two conflicting goals:
* maintain source back-compat as long as it is reasonable
* keep back-compat garbage to a minimum, eliminating it where possible

It really comes down to a maintainer decision, unless there is an overriding decision to purposefully break source back-compat.

To answer your question specifically, SET_MODULE_OWNER eases source back-compat in general, but it's main user is network drivers.

Jeff