Hi,
I've done it. Thanks for the road map.
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Roman Kurakin <[EMAIL PROTECTED]> writes:
: M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Roman Kurakin <[EMAIL PROTECTED]> writes:
: > : I have the following problem:
: > : module A
: > : int x;
: > :
: > : module B
: > : extern int x;
: > :
: > : Module A is loaded, module B can't be loaded cause of unknow 'x'.
: > : What should I do to make x global?
: >
: > Better to make module B depend on module A. Making it global is
: > generally a bad idea.
: >
: > in module A:
: > MODULE_VERSION(A, 1);
: >
: > In module B:
: > MODULE_DEPEND(B, A, 1, 1, 1);
: >
: Module dependence is not the goal.
Right. That's how symbols are visible to other modules.
Yes, it works. And it is still needed for class/subclass scheme.
: >
: > : PS. I am working on porting irda support for USB devices from NetBSD.
: > : The current model consists of two layers hw and sw. hw is the usb device
: > : driver. sw is some software layer the same for all device and it is a
: > : child on top of hw 'bus'. To make this working I need to add
: > : DRIVER_MODULE for each 'bus'. To make sw independent from the
: > : bus I need to export _driver and _class structures and put DRIVER_MODULE
: > : in 'bus' code instead of 'child'.
: >
: > Are you sure that you need to do this? I'm pretty sure that you can
: > create a base class irdabus and then derive all the hw modules that
: > implement irdabus from than and all the children will automatically
: > probe. No need to export the driver/class structures.
This was a bit wrong. You still need to export kobj_class (eq driver_t
structure,
DECLARE_CLASS).
: >
: I have a bit reversed case. In common case we have a driver for "bus"
: with many
: consumers. And we have children that declares itself via DRIVER_MODULE.
: If child could work on several buses it declares itself several times
: one for each
: bus. In my case I have several drivers that could be treated as bus
: driver for the
: same child:
:
: -----------USB------------
: | | |
: ustir uirda smth_else
: \ | /
: ---------irframe--------
:
: Imagine, if the network interface was implemented as a child of every
: network
: adapter. This is the same. In common case I'll put DRIVER_MODULE in a child
: for each bus and recompile after adding a new one. In this case I do no
: want to
: recompile the child for every new "bus" since child do not depend on
: such "bus"
: - it is the same for all. So we may call this a pseudo-device with
: unknown list
: of buses. I know, I could implement this other way, but I just want to
: play with
: newbus a bit and the original NetBSD driver was implemented this way.
I think I must have not been clear before. I thought gave a solution
to this that doesn't require a new DRIVER_MODULE for each new device.
Let me try again.
I'd hoped to say make ustir, uirda and smth_else all subclasses of a
irbridge class, just like we do for pci and cardbus today. Then
irframe would attach to irbridge and you'd only need to list
DRIVER_MODULE lines once. This isn't a reversed case at all. It is
actually quite common, but has been 'papered over' until now via
multiple DRIVER_MODULE lines, except in the case of pci/cardbus[*].
I can provide more details on actually doing this. Right now I'm
doing something similar for all the iic bridges that we have in the
kernel. The number of devices with iicbus children is way too large
and we can eliminate that issue via the technique. I'd be happy to
flesh it out a bit, or provide you with sample code if you need that.
For curious:
==============irda_bus==============
static device_probe_t irda_bus_probe;
static device_attach_t irda_bus_attach;
static device_detach_t irda_bus_detach;
static device_method_t irda_bus_methods[] = {
/* stub functions */
DEVMETHOD(device_probe, irda_bus_probe), /* aka match */
DEVMETHOD(device_attach, irda_bus_attach),
DEVMETHOD(device_detach, irda_bus_detach),
{0,0}
};
struct irda_bus_softc {
};
MODULE_VERSION(irda_bus, 1);
DEFINE_CLASS_0(irda_bus, irda_bus_driver, irda_bus_methods,
sizeof(struct irda_bus_softc));
===================================
================ustir================
Static device_probe_t ustir_match;
Static device_attach_t ustir_attach;
Static device_detach_t ustir_detach;
Static devclass_t ustir_devclass;
Static device_method_t ustir_methods[] = {
DEVMETHOD(device_probe, ustir_match),
DEVMETHOD(device_attach, ustir_attach),
DEVMETHOD(device_detach, ustir_detach),
{0,0}
};
MODULE_DEPEND(ustir, usb, 1, 1, 1);
MODULE_DEPEND(ustir, irda_bus, 1, 1, 1);
DECLARE_CLASS(irda_bus_driver);
DEFINE_CLASS_1(irda_bus, ustir_driver, ustir_methods,
sizeof(struct ustir_softc), irda_bus_driver);
DRIVER_MODULE(ustir, uhub, ustir_driver, ustir_devclass,
usbd_driver_load, 0);
==========================================
===================ir_frame=================
static device_probe_t irframe_match;
static device_attach_t irframe_attach;
static device_detach_t irframe_detach;
devclass_t irframe_devclass;
static device_method_t irframe_methods[] = {
DEVMETHOD(device_probe, irframe_match),
DEVMETHOD(device_attach, irframe_attach),
DEVMETHOD(device_detach, irframe_detach),
{0,0}
};
driver_t irframe_driver = {
"irframe",
irframe_methods,
sizeof(struct irframe_softc)
};
DRIVER_MODULE(irframe, irda_bus, irframe_driver, irframe_devclass, NULL,
NULL);
==========================================
Method functions are called from a subclass, so in base class you may
use stub functions. As I mentioned, you still need to export, in this case
irframe_driver. One bad thing, that with usb devices you can't use
USB_DECLARE_DRIVER(). In case of other such cases we could for
sure define USB_DECLARE_DRIVER_x().
PS. I'll cleanup a bit what I've done and will put ported drivers to
perforce. As
I usually do, I'll keep original driver via #ifdef, so it could be used
as a reference
material for usb driver porters.
I know that ustir/irframe were ported before from NetBSD, but a posted
link seems
to be dead. In any case I've also ported uirda. irframe_tty is on the
way in case I'll
find a hardware for testings.
rik
Warner
[*] There's still pci and cardbus DRIVER_MODULE lines in many drivers,
but they are almost not needed. There's a newbus bug that I've not
had the time to track down that prevents kldload from working
competely correctly in some cases (like when loading the cardbus
module). Once I get that fixed...
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
