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 <eapache@xxxxxxxxx> wrote:
> On Thu, Aug 30, 2012 at 3:14 AM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:
>> Evan Huus skrev 2012-08-30 04:31:
>>
>> On Wed, Aug 29, 2012 at 7:28 PM, Anders Broman <a.broman@xxxxxxxxxxxx>
>> 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-xmpp<tab><tab>
>>
>> instead of:
>>
>> vi
>>
>> epan/dissectors/packet-xmpp<tab><tab>[1]^H^H^H^H^H^H^H^H^H^H^Hxmpp<tab>/<tab><tab>
>>
>> [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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe