Vladimir Cotfas wrote: > Jan, > > I am using gmail from Windows. Please use the attached diffs if gmail > mangles stuff. BTW: here gmail *is* the company mail server. I have > re-attached a slight change. > > The "stray" comments help when quickly grepping for things. > > The stats *do not* map onto anything RTNET provides. They are just stats > that instrument low rtskb conditions and help in debugging when one > scratches his head and asks "WTF is going on?". > > I think the reason for using a rtskb pool is that the underlying driver > expects the packets to be transmitted to come from such a pool. I may be > wrong.
Nope, there is no such requirements. rtskb ownership passes around, and as long as you have it, you can queue that object as you like. But as rtskbs already have the hooks for queuing, you actually don't need special ring buffers. > > I do not intend to refactor the code further as of now. The only bit of > refactoring has to do with my resource allocation/freeing paranoia. I will > keep in mind your comments re: skb pool replacement. > > A good practice is that if you don't have to do anything in function then > exit from it as soon as possible, e.g. when the xmit function gets a NULL > rtskb then it has nothing to do, *regardless of a NULL skb being a bug*. What might be good practice in one context can be considered undesired style in another. > > C99 exists for a reason. Keeping the variable close to where you use them > [and not at the top of the function] is good practice. Just like you probably have coding style rules in your company, so do we have here. There are always exception possible, but this concrete example surely does not qualify for it - here. > > I am not open to comments re: code formatting/style. I am getting enough > grief from a Hungarian-notation aficionado at my other place of work. You > may have a more successful project/community if casual contributors don't > have to learn your project-specific coding rules. See, I'm switching between various coding styles every day. Almost every project (open source or customer) has its own. There is one thing I had to learn as well: Upstream dictates the style, not /me. RTnet is upstream here, and although it's far from being clean, but I'm trying to get it back on consistent kernel style tracks. That is required to improve readability and maintainability. Allowing arbitrary styles is neither acceptable in commercial code nor in (good) open source projects. > > For the time being this is the patch and the time I have allocated for > rtnetproxy. Splitting into 5 patches is just *make-work*. My patch fixes > things, *works* and corrects a problem that has been around for ages. We > have done our GPL bit and did enough due diligence to have it accepted. No, your "GPL bit" has to be fulfilled every time you deliver to your customer, independent if you are using unmodified or patched GPL code. Upstream merge is not part of the license terms but, as privately explained, generally of high value. You may have already forgot some of that values: I pointed out several critical bugs in your original code that you would otherwise had to debug on your own, maybe even after shipping as product. Now I would have to sort your changes (once time permits), identify the relevant bits, and try to merge them. You will end up with a hard to maintain private version, RTnet with something that is not as well tested as it could be. I'm not expecting you address my comments in real-time. You can keep them on your to-do list and address step by step once time permits. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
