Hi Wolfgang,

some more comments after looking at code and running a compiler:

...
>       * ksrc/drivers/can/rtcan_raw.c,
>       ksrc/drivers/can/sja1000/rtcan_sja1000.c,
>       ksrc/drivers/can/mscan/rtcan_mscan.c: timestamps are now read and
>       copied in rtcan_recv() and rtcan_tx_loopbcak().

...thus multiple times in the same IRQ context if there are multiple
packets pending. Do we gain enough from the new design that helps to
compensate the drawback (considering slow rtdm_clock_read()
implementations)? Moreover, we may see a feature one day that the RTDM
layer will provide you timestamps for an IRQ event (e.g. when the
handler will be running at higher latency as a thread).

...
> 
>       * ksrc/drivers/can/mscan/Kconfig, ksrc/drivers/can/sja1000/Kconfig,
>       ksrc/drivers/can/Kconfig: add more help for kernel parameters.

Suggestion: N x "depends on XYZ" => 1 x "if XZY != n ... endif"

...
>       * ksrc/drivers/can/sja1000/rtcan_sja1000.c,
>       ksrc/drivers/can/sja1000/rtcan_isa.c,
>       ksrc/drivers/can/sja1000/rtcan_mem.c,
>       ksrc/drivers/can/sja1000/rtcan_peak_pci.c,
>       ksrc/drivers/can/sja1000/rtcan_peak_dng.c: Remove rtcan_dev_free()
>       from rtcan_sja1000_unregister() to allow proper cleanup after the
>       device has been unregistered.

[2.4.33 build for x86]
rtcan_peak_dng.c: In function `rtcan_peak_dng_exit_one':
rtcan_peak_dng.c:315: warning: implicit declaration of function
`rtcan_free_dev'

[Not related to this change]
In order to use the parport dongle also with recent PnP ports (e.g. in
notebooks), you may want to have a look at the code I added to irqbench
for this purpose:

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/irqbench.c?v=SVN-trunk#496

The background is that once you unload the parport module, the port will
be powered off.

...
>       * src/drivers/Makefile, ksrc/drivers/can/*, scripts/Modules.frag,
>       src/utils/can/README: Replace "rtcan" with "can" in macro definitions
>       CONFIG_XENO_DRIVERS_RTCAN_* and module names xeno_rtcan_* to comply to
>       the common naming scheme.

Hmm, wouldn't shortening some file names also make sense then?

Jan


PS: 2.4 help patching and updating work nicely for me - except for
choices which is obviously a 2.4 bug. I saw that the kernel then
sometimes stuffs all information into the first item. Maybe scriptable
for Xenomai... :->

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to