Hello back, Thanks for your reviews on this idea of mine!
What I had also had in mind, that I came up with this idea, was something that I had found very confusing: ATM we've got functions of km-um communication in flow, vport, etc. We also got hyper-v switch port functions in vports. We've got DriverEntry callbacks spread in several files as well. The same with Datapath functionalities. It is all very confusing if you are new to this project. Having studied the linux version of the code some time ago, I must tell that that was much clearer: "actions.c" were actions, "flow.c" was flow, "flow_table.c" was flow table, "vport" was ports, etc (except for "datapath.c" which was quite datapath + netlink protocol + etc.). My belief here was that: a) splitting functions that deal with multiple components in several files should be considered b) if we are to do the port mapping, something like this would happen, in some measure c) if we are to do a), this will increase the number of files d) increasing the number of files, need for separate files into directories would arise e) putting files in directories, based on component, might help influencing the programmers to keep things more modular. Also, I've got another suggestion (very low priority): renaming the callbacks used by driver entries into their standard names (e.g. FilterAttach, FilterDetach) might help /make it more clear to new people to datapath-windows, who have some experience with NDIS. If you create a New NDIS project in Visual Studio, these are the names that are being used; these are also the names used in MSDN documentation. And I don't think there would be a problem with licensing here, since the automatically generated code for NDIS in "New Project -> NDIS" has no licensing associated, AFAIK. I have no problem with moving the files when the need arises. I'm only worrying that it would be more difficult / burden to do it later on. Say, for instance, we will add one day functionality for port mapping. This would add several new files, some of which hyper-v specific. If we are to put these into a "hyper-v" directory, they would be only few files, while other functionalities dealing with hyper-v are spread throughout OvsSwitch, OvsVPort, and perhaps some other files. What would your approach be? Should we keep all hyper-v plus other components in the main datapath-windows directory? In which cases we will consider necessary to move existing / new files to separate directories? Do you think it would be easy to have to move functionalities from various files (such as flow, vport, etc.) from within the main directory to specific folders later on (hyper-v, netlink, etc.)? Or it would simply be better keep all vport-associated functionatilities (datapath port, hyper-v port, hyper-v nic, netlink) within the same file? Thanks! Sam ________________________________________ From: Nithin Raju [nit...@vmware.com] Sent: Wednesday, August 06, 2014 9:47 PM To: Saurabh Shah Cc: Samuel Ghinet; dev@openvswitch.org Subject: Re: [ovs-dev] datapath-windows: Could we rename the files please? On Aug 6, 2014, at 11:07 AM, Saurabh Shah <ssaur...@vmware.com> wrote: > My 2 cents, I am not in favor of redoing the directory structure in the > anticipation of it becoming more complex. When/If it becomes complex, we > can do the re-structuring. I don¹t see any need to do it right now. I agree with Saurabh on this. Let there be a concrete problem (bug or otherwise) that a patch is trying to address. -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
