Dirk Eibach wrote: > Hello, > > I did some redesigning on my first draft. > - Now we have some kind of profile in include/rti2c.h. > - I got rid of some chunks of code that were not really needed. > - Linux kernel dependencies have been removed (I hope I catched all of > them)
Hmm, I would rather suggest the opposite: Unless you have to deviate from the original Linux API (which seems to exist in kernel 2.4 as well), I would prefer to keep structure and constant names identical. I see no technically problem ATM in including the original I2C Linux header, both in kernel and user space. Then I'm curious what /real-time/ application scenarios are behind the SMBus wrapping functions. Are you driving time-critical hardware via such a protocol? May other users do the same, or is this a special use case? Sorry, my knowledge about the SMBus is quite limited. The question for me is simply, if those helpers should become part of the official API specification or not. There are still some duplications in the headers /rti2c.h and /include/rti2c.h (I assume rti2c-api.h is just a copy of /include/rti2c.h without profile comments). Please avoid this. Everything the user needs to see should be in the profile header, and that can then be included by the driver header. And I think I found a bug (you may want to try CONFIG_XENO_OPT_DEBUG_RTDM): rti2c_adapter_register, e.g., uses an RTDM mutex, but I strongly suspect it (only?) runs in Linux context. Please check your locking in this regard, also the other way around (non-RT services in RT context - we currently lack automated checking for this). Another remark while cross-reading (which means: no guarantee I found all issues): correct error code for wrong context is EPERM (rti2c_ioctl_rt, RTI2C_RDWR). So far for now. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
