Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 31 August 2012 03:15 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ Having re-read the entire thread, I've gathered the following list of objections. I think it covers all of the concerns mentioned so far (in no particular order): 1 potential for file-name collisions 2 increased difficulty in using tab-completion 3 potential for less parallel make 4 more complicated to search dissector source 5 concern that the number of folders would scale as poorly as the number of files 6 concern that it wouldn't actually provide any benefit 1 and 2 are only issues with the original, rough draft of the naming scheme. The refined naming scheme proposed later in the thread does not have either issue. 3 is only an issue if we write the makefiles wrong. Now that somebody's mentioned it, hopefully we wouldn't make that mistake :) 4 is valid, but minor. I would hope that most developers use a tool like ctags, cscope, or similar to index the code. All of those tools will work regardless of how the source is layed out. Manual greps will be more complicated, but if you have to run a manual grep on a codebase the size of Wireshark's then I think there's already something wrong. 5 is reason to be conservative in our use of folders, but not reason to discard the idea. As long as we limit folders to groups with a large number of files (10+? more?) then they'll still provide a benefit. 1000 folders is way too many, but it's still better than 15000 files! 6 I'm not clear on, since the benefits seem so obvious to me. Perhaps I've just done a poor job of explaining. I simply feel that epan/dissectors/packet- bluetooth/ would be a good thing for the same reason that epan/dissectors/ is a good thing: it provides additional logical structure that turns a list (inefficient) into a tree (efficient). If people are more in favour of using patterned names like packet-bluetooth-* to denote that structure, then why do we use folders at all? As Jeff pointed out, we moved all the dissectors together into epan/dissectors/ for a reason. That reason still applies here. At this point I feel that I've said everything I can possibly say on the subject. If people are still generally against the idea then so be it, but I'm not going to argue the point anymore. [Graham Bloice said] Evan, Thanks for the list it was really helpful. FWIW my vote is not to change, I don't find the current layout difficult and I see no personal benefit if it were changed. Any changes to use subdirectories would inconvenience me as my preferred editor would then have to be set to search sub-directories when grepping for dissector stuff, as would my muscle-memory when grepping from the command line. However if the group think is to change things then I'll cope. I would support removing the packet- prefix though. Entirely unnecessary IMHO. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus skrev 2012-08-30 04:31: On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) h### comes from ITU (http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx) ITU-T Series of Recommendations H /itu-t/recommendations/index.aspx?ser=H: Audiovisual and multimedia systems I'm not sure we would like to have all of them in the same folder but that depends on the logic we want to apply, likewise some of those gsm protocol has nothing else in common than being used in Mobile system of GSM type (e.g not dissection for one protocol spread in several files) should UMTS and LTE have their own folders as well in that case? ANSI/CDMA? Perhaps it's more clear cut in aim dcerpc etc and makes more sense. Regards Anders Evan ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 3:14 AM, Anders Broman a.bro...@bredband.net wrote: Evan Huus skrev 2012-08-30 04:31: On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) h### comes from ITU (http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx) ITU-T Series of Recommendations H: Audiovisual and multimedia systems I'm not sure we would like to have all of them in the same folder but that depends on the logic we want to apply, likewise some of those gsm protocol has nothing else in common than being used in Mobile system of GSM type (e.g not dissection for one protocol spread in several files) should UMTS and LTE have their own folders as well in that case? ANSI/CDMA? Perhaps it's more clear cut in aim dcerpc etc and makes more sense. I was just going by the existing file names, so if they're not actually logically related then they shouldn't be grouped. Being conservative on a first pass makes sense, and we can see how it works out for the really obvious cases. Unless there are any other objections I'd like to propose we start with these four as a sort of trial run: - aim - bluetooth - dcerpc - xmpp And with the naming scheme: packet-xmpp/xmpp-whatever.c Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. regards, Roland On Thu, Aug 30, 2012 at 3:19 PM, Evan Huus eapa...@gmail.com wrote: On Thu, Aug 30, 2012 at 3:14 AM, Anders Broman a.bro...@bredband.net wrote: Evan Huus skrev 2012-08-30 04:31: On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) h### comes from ITU (http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx) ITU-T Series of Recommendations H: Audiovisual and multimedia systems I'm not sure we would like to have all of them in the same folder but that depends on the logic we want to apply, likewise some of those gsm protocol has nothing else in common than being used in Mobile system of GSM type (e.g not dissection for one protocol spread in several files) should UMTS and LTE have their own folders as well in that case? ANSI/CDMA? Perhaps it's more clear cut in aim dcerpc etc and makes more sense. I was just going by the existing file names, so if they're not actually logically related then they shouldn't be grouped. Being conservative on a first pass makes sense, and we can see how it works out for the really obvious cases. Unless there are any other objections I'd like to propose we start with these four as a sort of trial run: - aim - bluetooth - dcerpc - xmpp And with the naming scheme: packet-xmpp/xmpp-whatever.c Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
[Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? +1 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice graham.blo...@trihedral.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? I think it boils down to better structure and scalability. We have an enormous number of files in epan/dissectors/ and I fully expect it to continue to grow. The flat structure is already unwieldy and it's only going to get worse. Logically grouping certain dissectors reduces the number of items at the epan/dissectors/ level. It also makes it much easier to work on a single cluster: if you're working on some enhancements to the bluetooth dissectors, it's much easier to work in epan/dissectors/packet-bluetooth/ than to try and wade through all the other hundreds of files in epan/dissectors/ every time you need to open another bluetooth-related file. It should also make the groupings easier for new developers to grok. It's pretty obvious that everything in packet-bluetooth/ must be bluetooth-related, even if the filename is something like packet-hci_h4.c (which is a real bluetooth dissector file, for those who didn't know). *I* know that hci stands for Host/Controller Interface which is a bluetooth-related term, but only because I looked it up for the purposes of this email, and I still don't know what the h4 is. New developers shouldn't have to do that kind of research (or peek at the file header) to get an idea of what a dissector does. Arguably my last point could be fixed by just using better names in epan/dissectors/, but then you end up with names that are uncomfortably long: packet-bluetooth_host-controller-interface_hsomethingsomething4.c anyone? Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus skrev 2012-08-30 16:27: On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice graham.blo...@trihedral.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? I think it boils down to better structure and scalability. We have an enormous number of files in epan/dissectors/ and I fully expect it to continue to grow. The flat structure is already unwieldy and it's only going to get worse. Logically grouping certain dissectors reduces the number of items at the epan/dissectors/ level. It also makes it much easier to work on a single cluster: if you're working on some enhancements to the bluetooth dissectors, it's much easier to work in epan/dissectors/packet-bluetooth/ than to try and wade through all the other hundreds of files in epan/dissectors/ every time you need to open another bluetooth-related file. - If we make sub directories I'd vote for epan/dissectors/bluetooth It should also make the groupings easier for new developers to grok. It's pretty obvious that everything in packet-bluetooth/ must be bluetooth-related, even if the filename is something like packet-hci_h4.c (which is a real bluetooth dissector file, for those who didn't know). *I* know that hci stands for Host/Controller Interface which is a bluetooth-related term, but only because I looked it up for the purposes of this email, and I still don't know what the h4 is. New developers shouldn't have to do that kind of research (or peek at the file header) to get an idea of what a dissector does. Arguably each dissector should have a short description of what it does and preferably references to protocol descriptions including an explanation of the acronym. Arguably my last point could be fixed by just using better names in epan/dissectors/, but then you end up with names that are uncomfortably long: packet-bluetooth_host-controller-interface_hsomethingsomething4.c anyone? I'm not convinced having a small number of subdirectories alleviates the problem of a large number of files in epan/dissectors trying to group a larger number of dissectors in a logical way might not be easy. If we end up with 100 subdirectories that wouldn't be nice either. That said moving dissectors split over many large files might make sense, if the files are small perhaps they should be folded into the main one as modules instead. Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On 30/08/2012 15:27, Evan Huus wrote: On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice graham.blo...@trihedral.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? I think it boils down to better structure and scalability. We have an enormous number of files in epan/dissectors/ and I fully expect it to continue to grow. The flat structure is already unwieldy and it's only going to get worse. Logically grouping certain dissectors reduces the number of items at the epan/dissectors/ level. It also makes it much easier to work on a single cluster: if you're working on some enhancements to the bluetooth dissectors, it's much easier to work in epan/dissectors/packet-bluetooth/ than to try and wade through all the other hundreds of files in epan/dissectors/ every time you need to open another bluetooth-related file. It should also make the groupings easier for new developers to grok. It's pretty obvious that everything in packet-bluetooth/ must be bluetooth-related, even if the filename is something like packet-hci_h4.c (which is a real bluetooth dissector file, for those who didn't know). *I* know that hci stands for Host/Controller Interface which is a bluetooth-related term, but only because I looked it up for the purposes of this email, and I still don't know what the h4 is. New developers shouldn't have to do that kind of research (or peek at the file header) to get an idea of what a dissector does. Arguably my last point could be fixed by just using better names in epan/dissectors/, but then you end up with names that are uncomfortably long: packet-bluetooth_host-controller-interface_hsomethingsomething4.c anyone? If the directory structure is changed, I think that it would be sensible to group dissectors by the organisation responsible for the protocol specification, e.g, all GSM/UMTS/LTE dissectors would go in a 3GPP directory, etc. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus wrote: On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice graham.blo...@trihedral.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? I think it boils down to better structure and scalability. We have an enormous number of files in epan/dissectors/ and I fully expect it to continue to grow. The flat structure is already unwieldy and it's only going to get worse. Unwieldy how? Except for having to know not to do vi epan/dissectors/tabtab (for fear of too many pages of output) I don't find the directory unwieldy. I admit I don't use any kind of graphical interface to look in the directory... I imagine pointing a file explorer in there might be somewhat painful. Logically grouping certain dissectors reduces the number of items at the epan/dissectors/ level. It also makes it much easier to work on a single cluster: if you're working on some enhancements to the bluetooth dissectors, it's much easier to work in epan/dissectors/packet-bluetooth/ than to try and wade through all the other hundreds of files in epan/dissectors/ every time you need to open another bluetooth-related file. Don't you get the same thing by naming the files packet-high_level_protocol-subprotocol, etc.? It should also make the groupings easier for new developers to grok. It's pretty obvious that everything in packet-bluetooth/ must be bluetooth-related, even if the filename is something like packet-hci_h4.c (which is a real bluetooth dissector file, for those who didn't know). *I* know that hci stands for Host/Controller Interface which is a bluetooth-related term, but only because I looked it up for the purposes of this email, and I still don't know what the h4 is. New developers shouldn't have to do that kind of research (or peek at the file header) to get an idea of what a dissector does. Arguably my last point could be fixed by just using better names in epan/dissectors/, but then you end up with names that are uncomfortably long: packet-bluetooth_host-controller-interface_hsomethingsomething4.c anyone? Well, no, but how about packet-bthci_h4.c (to match the naming convention of the other bluetooth files)? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 1:46 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Evan Huus wrote: On Thu, Aug 30, 2012 at 9:45 AM, Graham Bloice graham.blo...@trihedral.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Evan Huus Sent: 30 August 2012 14:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/ On Thu, Aug 30, 2012 at 9:23 AM, Roland Knall rkn...@gmail.com wrote: Hi Would you like to enforce a value for the minimum number of subsequent files in the subdirectories? I would assume you'd need 5 or 6 files at least to make a folder worthwhile, but I don't think that's a hard rule. None of the groups proposed for the initial run have less than 14. As I wrote the opensafety package, I would like to split it up a little bit to make it more maintainable, as well as include two new subdissectors, which use the openSAFETY protocol, but are not necessarily part of it. For the subdissectors, it depends on how tightly they are bound to opensafety. If they could theoretically be carried on other protocols as well then they shouldn't be grouped with it, but if they are restricted to opensafety (in the sense that they use some special fields or features of opensafety and so actually couldn't be carried on, say, TCP, without changing the protocol), then they can logically be grouped with it. Again, probably not a hard rule, but a good guideline. [Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? I think it boils down to better structure and scalability. We have an enormous number of files in epan/dissectors/ and I fully expect it to continue to grow. The flat structure is already unwieldy and it's only going to get worse. Unwieldy how? Except for having to know not to do vi epan/dissectors/tabtab (for fear of too many pages of output) I don't find the directory unwieldy. That's part of it - I still do that accidentally on occasion. The other part of it is just that the number of files is overwhelming. It's not necessarily inefficient for the computer, but it is certainly inefficient for a mental model of the source structure, and it feels daunting, which is something we want to avoid in order to encourage new developers. I know when I checked out the source tree for the very first time I looked at the size of it and had very much a where do I start?! moment. I admit I don't use any kind of graphical interface to look in the directory... I imagine pointing a file explorer in there might be somewhat painful. It is. I tend not to browse the tree with a GUI, but I have in the past and it was a nightmare. Logically grouping certain dissectors reduces the number of items at the epan/dissectors/ level. It also makes it much easier to work on a single cluster: if you're working on some enhancements to the bluetooth dissectors, it's much easier to work in epan/dissectors/packet-bluetooth/ than to try and wade through all the other hundreds of files in epan/dissectors/ every time you need to open another bluetooth-related file. Don't you get the same thing by naming the files packet-high_level_protocol-subprotocol, etc.? To a point, but shell auto-complete is much more efficient if it's a sub-directory. It should also make the groupings easier for new developers to grok. It's pretty obvious that everything in packet-bluetooth/ must be bluetooth-related, even if the filename is something like packet-hci_h4.c (which is a real bluetooth dissector file, for those who didn't know). *I* know that hci stands for Host/Controller Interface which is a bluetooth-related term, but only because I looked it up for the purposes of this email, and I still don't know what the h4 is. New developers shouldn't have to do that kind of research (or peek at the file header) to get an idea of what a dissector does. Arguably my last point could be fixed by just using better names in epan/dissectors/, but then you end up with names that are uncomfortably long: packet-bluetooth_host-controller-interface_hsomethingsomething4.c anyone? Well, no, but how about packet-bthci_h4.c (to match the naming convention of the other bluetooth files)? That would certainly help, but again it's not immediately obvious to new devs that packet-bt*.c is bluetooth, and spelling out packet-bluetooth_*.c gives pretty long names. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 06:34:05PM +0100, Mike Morrin wrote: If the directory structure is changed, I think that it would be sensible to group dissectors by the organisation responsible for the protocol specification, e.g, all GSM/UMTS/LTE dissectors would go in a 3GPP directory, etc. ... and dissectors for protocols which have got RFC number in rfc^W ietf/ directory? :-) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
[Graham Bloice said] Some folks have articulated the drawbacks (to them) of making these changes but I haven't seen any actual advantages listed. Can anyone list them as they see it? Well I used to work on packet-dcm for a while, and considering myself a novice, it was painful to find 'my' files after all the packet-dcep Try to type the filename in the directory. If you don't get all 10 character right, you're off. So for me it would have been a benefit to take the big ones out to allow typing in the file explorer. fold into one large file I really hate the 3100 lines of protocol definitions in packet-dcm.c , but since i didn't consider the protocol that important, I never dared to ask for a 2nd .c file. And comments were not that friendly, when I had it in the include file. In addition, I also don't see the benefit in the 'packet-' prefix. And since we are at it, the 'epan' directory for sure makes sense to all those working on the framework, but for me as a dissector contributor, it's just a deeper hierarchy. David ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On 08/30/2012 04:31 AM, Evan Huus wrote: On Wed, Aug 29, 2012 at 7:28 PM, Anders Bromana.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) Evan Oke, I'm still missing the quantitative rationale here. When I'm looking at the number of dissector files in trunk I get: jaap@phoenix:~/src/wireshark/trunk/epan/dissectors$ ls -1 | grep ^packet | wc -l 1501 Your list gives 23+111+23+33+12+15+14 = 231, that's a mere 15%. That doesn't really alleviate the problem. Thanks, Jaap ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus wrote: On Thu, Aug 30, 2012 at 1:46 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Unwieldy how? Except for having to know not to do vi epan/dissectors/tabtab (for fear of too many pages of output) I don't find the directory unwieldy. That's part of it - I still do that accidentally on occasion. The other part of it is just that the number of files is overwhelming. It's not necessarily inefficient for the computer, but it is certainly inefficient for a mental model of the source structure, and it feels daunting, which is something we want to avoid in order to encourage new developers. I know when I checked out the source tree for the very first time I looked at the size of it and had very much a where do I start?! moment. I'm relatively new to Wireshark development (only a few years), so I remember that moment too. However, I'm not sure that organizing things into subdirectories would really help that much. What you've identified though, is a real thing that might be addressed, which is that regardless of how the files are physically organized, it would be useful to structure things to aid human beings who look at and work with the source files. Doxygen, which is already lightly supported, could help there without a lot of additional effort. I think that might be a better way to approach this problem than rearranging the source code directory structure. What do you think? Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 6:21 PM, Jaap Keuter jaap.keu...@xs4all.nl wrote: On 08/30/2012 04:31 AM, Evan Huus wrote: On Wed, Aug 29, 2012 at 7:28 PM, Anders Bromana.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) Evan Oke, I'm still missing the quantitative rationale here. When I'm looking at the number of dissector files in trunk I get: jaap@phoenix:~/src/wireshark/trunk/epan/dissectors$ ls -1 | grep ^packet | wc -l 1501 Your list gives 23+111+23+33+12+15+14 = 231, that's a mere 15%. That doesn't really alleviate the problem. I don't think the intent in the original proposal was that this would magically reduce epan/dissectors/ to a fraction of its original size, but 15% is a non-trivial improvement. Also, my list was only a quick scan based on file-name similarities. I'm sure there are other logical groups that aren't as obvious simply because the file names are inconsistent. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Thu, Aug 30, 2012 at 8:29 PM, Ed Beroset bero...@mindspring.com wrote: Evan Huus wrote: On Thu, Aug 30, 2012 at 1:46 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Unwieldy how? Except for having to know not to do vi epan/dissectors/tabtab (for fear of too many pages of output) I don't find the directory unwieldy. That's part of it - I still do that accidentally on occasion. The other part of it is just that the number of files is overwhelming. It's not necessarily inefficient for the computer, but it is certainly inefficient for a mental model of the source structure, and it feels daunting, which is something we want to avoid in order to encourage new developers. I know when I checked out the source tree for the very first time I looked at the size of it and had very much a where do I start?! moment. I'm relatively new to Wireshark development (only a few years), so I remember that moment too. However, I'm not sure that organizing things into subdirectories would really help that much. What you've identified though, is a real thing that might be addressed, which is that regardless of how the files are physically organized, it would be useful to structure things to aid human beings who look at and work with the source files. Doxygen, which is already lightly supported, could help there without a lot of additional effort. I think that might be a better way to approach this problem than rearranging the source code directory structure. What do you think? It might not help a lot, but it will help a little. Doxygen is a good tool which we should probably be using more - perhaps that should be its own thread? - but its use doesn't exclude trying to find a logical way to structure the source. Also, I would hardly call this a rearrangement. All we're trying to do is make some existing structure a bit more explicit. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Having re-read the entire thread, I've gathered the following list of objections. I think it covers all of the concerns mentioned so far (in no particular order): 1 potential for file-name collisions 2 increased difficulty in using tab-completion 3 potential for less parallel make 4 more complicated to search dissector source 5 concern that the number of folders would scale as poorly as the number of files 6 concern that it wouldn't actually provide any benefit 1 and 2 are only issues with the original, rough draft of the naming scheme. The refined naming scheme proposed later in the thread does not have either issue. 3 is only an issue if we write the makefiles wrong. Now that somebody's mentioned it, hopefully we wouldn't make that mistake :) 4 is valid, but minor. I would hope that most developers use a tool like ctags, cscope, or similar to index the code. All of those tools will work regardless of how the source is layed out. Manual greps will be more complicated, but if you have to run a manual grep on a codebase the size of Wireshark's then I think there's already something wrong. 5 is reason to be conservative in our use of folders, but not reason to discard the idea. As long as we limit folders to groups with a large number of files (10+? more?) then they'll still provide a benefit. 1000 folders is way too many, but it's still better than 15000 files! 6 I'm not clear on, since the benefits seem so obvious to me. Perhaps I've just done a poor job of explaining. I simply feel that epan/dissectors/packet-bluetooth/ would be a good thing for the same reason that epan/dissectors/ is a good thing: it provides additional logical structure that turns a list (inefficient) into a tree (efficient). If people are more in favour of using patterned names like packet-bluetooth-* to denote that structure, then why do we use folders at all? As Jeff pointed out, we moved all the dissectors together into epan/dissectors/ for a reason. That reason still applies here. At this point I feel that I've said everything I can possibly say on the subject. If people are still generally against the idea then so be it, but I'm not going to argue the point anymore. All the best, Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Joerg Mayer wrote: What I'd like to do is put these dissectors that belong *to a single protocol* into a subdirectory of that name, i.e. move them to xmpp/packet-conference.c xmpp/packet-conference.h xmpp/packet-core.c xmpp/packet-core.h xmpp/packet-gtalk.c xmpp/packet-gtalk.h xmpp/packet-jingle.c xmpp/packet-jingle.h xmpp/packet-other.c xmpp/packet-other.h xmpp/packet-utils.c xmpp/packet-utils.h xmpp/packet-xmpp.c- special case, main protocol name xmpp/packet-xmpp.h- special case, main protocol name What do you think? I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here I also like being able to, for example: grep tvb_get_ptr epan/dissectors/packet-*.c instead of: grep tvb_get_ptr epan/dissectors/packet-*.c epan/dissectors/*/packet-*.c ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Wed, Aug 29, 2012 at 11:47 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: Joerg Mayer wrote: What I'd like to do is put these dissectors that belong *to a single protocol* into a subdirectory of that name, i.e. move them to xmpp/packet-conference.c xmpp/packet-conference.h xmpp/packet-core.c xmpp/packet-core.h xmpp/packet-gtalk.c xmpp/packet-gtalk.h xmpp/packet-jingle.c xmpp/packet-jingle.h xmpp/packet-other.c xmpp/packet-other.h xmpp/packet-utils.c xmpp/packet-utils.h xmpp/packet-xmpp.c- special case, main protocol name xmpp/packet-xmpp.h- special case, main protocol name What do you think? I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c That should avoid file-name conflicts and work well with existing muscle-memory. A good shell will even complete the /xmpp- in a single tab assuming there are no makefiles in the directory to screw things up. (That's another question though - do we keep one top-level makefile in epan/dissectors/, or do we add one in each sub-directory?) I also like being able to, for example: grep tvb_get_ptr epan/dissectors/packet-*.c instead of: grep tvb_get_ptr epan/dissectors/packet-*.c epan/dissectors/*/packet-*.c That's what tools like cscope [1] are for :) Alternatively, there is a nicer way with grep: grep -R --include=packet-*.c tvb_get_ptr epan/dissectors/ [1] http://cscope.sourceforge.net/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) Jut my 2 Cents Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2012-08-30 00:29: Evan Huus wrote: I'm not 100% convinced either way, but I have to admit I do like having all the dissectors in the same directory. make -j 40 (on my 32-vCPU SPARC) works better that way ;-). I'm pretty sure an autotools-generated Makefile will already recurse to fill the given job-count as long as there aren't any weird dependencies in place, so it shouldn't make any difference. Can't speak for cmake or windows builds. Only if all the files are in one Makefile (e.g., epan/dissectors/Makefile). If each subdir has its own Makefile then each directory is processed one at a time (in my experience). More seriously, I imagine I'd find it easier to do: vi epan/dissectors/packet-xmpptabtab instead of: vi epan/dissectors/packet-xmpptabtab[1]^H^H^H^H^H^H^H^H^H^H^Hxmpptab/tabtab [1] insert grumpy remark here Fair enough. So another tweak to the suggested naming: packet-xmpp/xmpp-whatever.c In fact taking your suggestion of removing packet- from all the file names would also achieve the same thing. I'm not particularly fond of the idea - just being conservative perhaps; but how many subdirectories are acceptable before it gets out of hand - 1000, one for every protocol in WS or a smaller number ;-) I expect most dissectors will stay in the root of epan/dissectors/. My understanding is that this would only be in a few select cases (bluetooth and xmpp are the ones that come to mind) where there is a clear logical grouping of a large number (16 for bluetooth, 14 for xmpp) of files. It makes sense to put them in their own folder. I just gave epan/dissectors/ a quick scan. Here are the other large groupings that immediately stand out: - aim (23 files) - dcerpc (111 files) - gsm (23 files) - h### (33 files) (is there a better generic name for this category?) - ipmi (12 files) - smb (15 files) - zbee (14 files) There are lots and lots of smaller groups of 4-5 files, but I wouldn't expect them to get their own folder. More input is always welcome :) Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Evan Huus wrote: I've never understood why they're all prefixed with packet- anyways, the fact that they're in epan/dissectors should be enough? Because they were originally in the top-level directory (!, at least until you consider how few dissectors Wireshark^WEthereal originally had). They were stuck there until the CVS-SVN migration which allowed the files to be moved while keeping their history. I have occasionally wondered whether we should strip off the packet- part, but I think I've just gotten used to it. It does sorta make it obvious from just the file name (excluding the path information) that it's a dissector (except for packet-range.* in the top-level directory, hmmm). ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Sorry to reply to myself, but I forgot the second half of my idea: On Sat, Aug 25, 2012 at 11:19:06AM +0200, Joerg Mayer wrote: Hello List, a discussion hidden in the bugtracker (id=7639) reminded me of something I have wanted to ask for a while: We have an (almost) flat structure in epan/dissectors/ and do additional structuring via file names instead, e.g. look at packet-xmpp-conference.c packet-xmpp-conference.h packet-xmpp-core.c packet-xmpp-core.h packet-xmpp-gtalk.c packet-xmpp-gtalk.h packet-xmpp-jingle.c packet-xmpp-jingle.h packet-xmpp-other.c packet-xmpp-other.h packet-xmpp-utils.c packet-xmpp-utils.h packet-xmpp.c packet-xmpp.h other examples are packet-dcercp*, packet-aim*, packet-gsm_*, packet-bt* and several more. What I'd like to do is put these dissectors that belong *to a single protocol* into a subdirectory of that name, i.e. move them to xmpp/packet-conference.c xmpp/packet-conference.h xmpp/packet-core.c xmpp/packet-core.h xmpp/packet-gtalk.c xmpp/packet-gtalk.h xmpp/packet-jingle.c xmpp/packet-jingle.h xmpp/packet-other.c xmpp/packet-other.h xmpp/packet-utils.c xmpp/packet-utils.h xmpp/packet-xmpp.c- special case, main protocol name xmpp/packet-xmpp.h- special case, main protocol name What do you think? Second part: Move the plugins into the epan/dissectors/ directory. It's been irritating me for quite some time to have dissector stuff outside epan. Thanks Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/
Hello Joerg, [snip] What I'd like to do is put these dissectors that belong *to a single protocol* into a subdirectory of that name, i.e. move them to [snip] xmpp/packet-other.c xmpp/packet-other.h xmpp/packet-utils.c xmpp/packet-utils.h These kind of file names could be in every protocol... What do you think? Based on experience with another open source C project where I did segregate files into sub-folders and tried to simplify the file names by utilizing sub-directories, you will likely have file naming conflicts between protocols if you remove the protocol name from the file. C file names must be unique in the build (for most compilers and linkers that I have used). Best Regards, Steve -- http://steve.kargs.net/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
