Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

chip info in procfs

2006-03-10
2013-06-04
  • Hi,
    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.

    Sergei

     
    • Pavel Pisa
      Pavel Pisa
      2006-03-11

      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
      aspect.)
      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
      class_device_create_file(this_dev, class_device_attr_xxx);
      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
      more features.

      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
      possibilities.

      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.

      Best wishes

                   Pavel Pisa

       
    • Pavel,
      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.

      Sergei