Hi, > Johannes, thanks for all of your comments! I will need some time to work > through them, though, please be patient. > > Johannes Berg wrote: > > 00-0F-0F (hex) Real ID Technology Co., Ltd. > > 000F0F (base 16) Real ID Technology Co., Ltd. > > 9F Hanmi B/D 192-19 > > Nonhyeon-Dong > > Gangnam-Gu Seoul 135-010 > > KOREA, REPUBLIC OF > > > > Have you asked them about using their OUI? > > Nah, sorry about that - I didn't get 0x000FACFF meant 'null' in the > first place, Actually I was looking at Draft 2.0 - 2.08/09 seems to have this updated. And no, I don't really have access to the documents. > and since I don't have access to an OUI yet, I selected > this value by random. I still hope nobody seriously wants my skeleton > module in the kernel code though. Heh, right. > BTW... do you know which OUI in that case (at devel time, this is an > university project, afaik the university does not have an OUI I can use) > makes sense for stuff like that? I believe there is a reserved range, > but I don't know for what reason it's reserved, and if I should use it > to avoid misunderstandings. I don't think there is a reserved OUI. > [do you really think I should to copy the style of rate control? i don't > like it at all. they have KBs of (IMHO) not very useful code instead of > keeping it to the point? Even in the Kconfig. Please correct me if I got > this wrong.] Depends what you mean by that? I think you should force one algorithm to be built in -- just like rate control. I also think you should take a look at abstracting the API like rate control to not expose so many internal data structures. Alternatively, just don't make them kernel modules but require building the algorithms into mac80211.ko anyway. > I know that, as I'm pretty new to kernel coding. Should I get me some > mentor from the kernel mentors project, or are you willing to correct my > stupid beginner mistakes all the time? Seems fine at this point, I take it you've looked through http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches and the links at the bottom of that page. Also Documentation/CodingStyle, and checkpatch etc. but that seemed fairly clean this time around, so I guess you did. What I didn't like about your patches was (1) the cramped style with so few empty lines, and (2) the API issue I mentioned. > Also: As you still haven't said anything about my ops struct, I deem you > think I have made a somewhat reasonable selection here? Not sure what to say there -- you don't really have a choice which functions to make virtual. The timer thing seems a little odd, either the algorithm should do everything or nothing, imho. I don't think it's necessary to split this into an ops and a registration struct though. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
