On Thu, Aug 30, 2012 at 6:21 PM, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> On 08/30/2012 04:31 AM, Evan Huus wrote:
>>
>> 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 :)
>>
>> 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.
