Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Hi Christoper,

LIGHTCAP,CHRISTOPHER A wrote:
>=20
> Jan,
>=20
> Thanks for such a quick response! We've made good progress with the

Indeed, I'm impressed!

> RTnet Arcnet driver but have a few questions about code which doesn't
> quite match up to the existing examples.
>=20
> And I have little experience with designing network drivers (or any
> driver!) .. therefore the questions might seem basic.
>=20
> 1.) The original arcnet driver does not call alloc_etherdev but rather
> alloc_netdev (shown below). Can I still change this function call like
> suggested in your porting documenation? What effect will this have on
> the program?
>=20
> BEFORE
>=20
> struct net_device *alloc_arcdev(char *name)
> {
>     struct net_device *dev;
>=20
>     dev =3D alloc_netdev(sizeof(struct arcnet_local),
>                name && *name ? name : "arc%d", arcdev_setup);
>     if(dev) {
>         struct arcnet_local *lp =3D (struct arcnet_local *) dev->priv;
>         spin_lock_init(&lp->lock);
>     }
>=20
>     return dev;
> }
>=20
> AFTER
>=20
> struct rtnet_device *alloc_arcdev(char *name)
> {
>     struct rtnet_device *dev;
>=20
>     /*** RTnet ***/
>     dev =3D rt_alloc_etherdev(sizeof(struct arcnet_local)); // etherdev=
?
>    =20
>     rtdev_alloc_name(dev, "rtarc%d");
>     rt_rtdev_connect(dev, &RTDEV_manager);
>     RTNET_SET_MODULE_OWNER(dev);
>     dev->vers =3D RTDEV_VERS_2_0;
>     /*** RTnet ***/
>=20
>     if(dev) {
>         struct arcnet_local *lp =3D (struct arcnet_local *) dev->priv;
>         rtdm_lock_init(&lp->lock); /*** RTnet ***/
>     }
>=20
>     return dev;
> }

We have rtdev_alloc instead, but that's not exported so far. If you need
it, it's trivial to add such an export (i.e. feel free to add this to
your patch). In this case, you will likely have to do a similar
initialisation of the device structure like it is now done in
rt_alloc_etherdev for Ethernet. I guess your handler arcdev_setup is
responsible for this in the original driver.

>=20
> 2.) In your example, you initialize the skb_pool in the probe function

Which example do you mean?

> and if the return value is less than twice the ring size then you
> release the skb_pool and call a few 'cleanup' functions.
>=20
> e.g.     pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, lp->dma_addr=
);
>=20
>    I'm not sure how it works, but I cannot this function because the
> struct arcnet_local does not have a field called 'dma_addr'. So my
> question is .. is dma_addr disguised under another name in the
> arcnet_local struct? and if not do I even need to call this function?

That's definitely driver-specific. If you did not request this kind of
resource earlier, you do not have to release it here on error. Rather
check your driver carefully what might have to be cleaned up when
something fails.

> [...]
>=20
> 3.) Ok. last question. It seems like I have a problem with module
> dependencies. The arcnet driver is set up to be loaded as four separate=

> modules: arcnet.ko (the foundation), arc-rawmode.ko (provides rawmode
> encapsulation), com20020.ko (support for chipset), and com20020-pci.ko
> (support for pci-board).
>=20
> I've done my homework and created four rt modules that compile and load=

> into the kernel.. but the problem is that I cannot get them to load wit=
h
> 'rtnet start'. How do I specify dependencies in the 'rtnet.conf' file?
> My dilemna is that if I specify com20020-pci without any extra work..
> the program will not run because it cannot load the module without its
> dependencies.. BUT I cannot load rt_arcnet.ko and rt_com20020.ko before=

> running 'rtnet start' because they both depend on the module rtnet!!

Yeah, I see. This actually reminds me of the fact that the installation
process and, as a result, the startup scripting need some renovation.
The way it is now dates back to the days where RT applications where
typically kernel modules as well. In fact we should have the same
problem with the recently added RT-WLAN driver as well. Daniel just
didn't test a full RTnet setup yet as far as I heard.

If we assume that modules go to /lib/modules/<kernel-version>/rtnet by
default e.g. and that depmod will be executed (or we trigger its
execution), then modprobe could be used in the startup script, and
missing components will get dragged in automatically - kind of standard..=
=2E

>=20
> So I feel like I'm in a bit of a catch-22. Please tell me how to get
> around this problem.

Well, as an intermediate solution we could add another variable to
rtnet.conf, let's say RT_ADDON_MODULES, that lists all modules that have
to be loaded after rtnet.ko but before the driver. This could also
include rtpacket.ko, thus making this component optional wrt the rtnet
start script. A simple

for mod in $RT_ADDON_MODULES; do insmod $RTNET_MOD/$mod$MODULE_EXT; done

would take care of the list in the script. Do you have scripting
experiences to add this?

But we definitely need refactoring of the installation process and the
startup script. Many people already asked for multi-device setup,
something that is not addressed by the current script design. I have no
ideas on this yet, though.


Hmm, BTW, do you actually *need* the start script as it is at all???
Will you run RTmac/TDMA over ARCNET (because that is what the script is
mostly about!)? Maybe it's an even easier way for you to write your own
startup/cleanup script then, just by picking up the interesting pieces
from existing code and docs.

>=20
> Thank you so much for your help.
>=20
> Chris Lightcap
> University of Florida
>=20

Looking forward to hear about the first successful experiments!

Jan