Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
It is quite useful to have chip info readily available for debugging and troubleshooting purposes. Chip info can be split into two categories: general and chip specific. Example of general info is chip address and example of specific info is receive buffer N overflow error.
Probably the right place for this is sysfs. I looked at the lincan sources and it seemed that it was not prepared for that. On the other hand there are some hooks for procfs. I know that adding yet another entry to already messy procfs is discouraged but it seems like a path of least resistance at the moment ;-)
So, in this context I added a function that adds chip_info entry to the procfs from proc.c:add_channel_to_procdir(). It generates as much info as possible from canchip_t struct and then calls chip specific function that generates additional info from chip->chip_data. If there is interest I’ll post a patch.
Hello Sergei and others,
I have this statistics support problem on my TODO list
for long time already. But I cannot find time to do that right.
There should be chip type independent IOCTL to obtain
basic error counters information, number of transfered bytes
and messages. This should be per chip information and data
gathering structure with atomic_t counters should be part
of canchip_t. The internal structure should be independent
of IOCTL/user-space utilized one. I would probably tend
to use structure fields same as in can4linux driver,
because I do not like to bring to life yet another standard.
As for /proc and /sysfs, there is again main problem
how to do that portable way. My long term aim is to
move code to register minor and device as whole to the
system into sysdep_lnx.c.
(By the way I hate minors at all but light on end of tunnel
shown by Richard Gooch seems to gone out. I have to admit,
that Windows Driver Model is more advanced in this specific
The proc and sysfs registration should go to system
specific source files as well.
We would like to add system glue for QNX, RTEMS and may
it be Windows in future.
The setup and finalization code has been restructured
already, so actual model where all candevice_t and canchip_t
structures are allocated first and then go through initialization
phases, could be simply changed to new device PnP driven model
of latest 2.6.x kernels. PCI and USB could work same way even
for 2.4.x (I have done it that way in uLan driver), but ISA would suck,
because there are no platform devices in 2.4.x series.
I am reluctant to do this major change before we can phase out
2.4.x support. But more of our university partner companies
still rely on 2.4.x in their industrial applications.
The LinCAN driver sources (proc.c) contains glue to add some
proc entries portable way. There are created directories
and links to devices. Addition of file with some information
should not be problem.
But it would be better to use /sysfs which is more proposed now.
Even, that LinCAN has not switched to new device model yet,
it registers its class and class instances, so there is anchor
where can be added attributes by simple calls of
This should be clear from comments and code in main.c.
In show_xxx(struct class_device *cdev, char *buf) you can get
back to can message object by class_get_devdata(cdev).
The chip or board data can be accessed from this point up.
Again, my longer goal is to fully separate minor registration
structure from message objects. This would enable to represent
and open even full can cards with more communication objects
as one character device and build proper queues routing and
automatic IDs and masks configuration of the chip if required.
The internal queues design is fully prepared even for such setup.
So it would be better to do this change first and then to add
May it be, that for actual both 2.4.x and 2.6.x Linux kernels
support /proc is more appropriate still.
I would like to know what LinCAN users thinks about these
I would be happy, if effort could be coordinated and fully
integrated into LinCAN mainline CVS. I would like to integrate
even more chips and devices support. On the other hand, I do
not promise to integrate each contribution, because I am trying
to keep code maintainable and I do not like to close some
conceptual open doors for future enhancements by code
which blocks them. I would like to have chip drivers
and boards support as much as possible independent on
specific system for example. Not everywhere true still,
but I would like to not make it worse.
well, I too prefer the "right way". Unfortunately those pesky real life necessities tend to get in the way and demand immediate attention ;-)
As I said, adding chip info to procfs was a very easy/minor change to lincan and allowed to see error counters, etc. for debugging purposes.