Date:	Thu, 4 Nov 2010 19:28:06 -0700
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	Joe Perches <joe@...ches.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/15] RFC: create drivers/net/legacy for ISA, EISA, MCA drivers

On Thu, Nov 4, 2010 at 14:20, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:
> On 10-10-29 08:01 PM, Jeff Kirsher wrote:
>> On Fri, 2010-10-29 at 15:08 -0700, Joe Perches wrote:
>>> On Fri, 2010-10-29 at 17:26 -0400, Paul Gortmaker wrote:
>>>> On 10-10-28 09:48 PM, Joe Perches wrote:
>>>>> On Thu, 2010-10-28 at 21:19 -0400, Paul Gortmaker wrote:
>>>>>> The drivers/net dir has a lot of files - originally there were
>>>>>> no subdirs, but at least now subdirs are being used effectively.
>>>>>> But the original drivers from 10+ years ago are still right
>>>>>> there at the top.  This series creates a drivers/net/legacy dir.
>>>>> I like this idea.
>>>>> I suggest a bit of a further grouping by using a
>>>>> drivers/net/ethernet directory and putting those
>>>>> legacy drivers in a new subdirectory
>>>>> drivers/net/ethernet/legacy.
>>>> That is a substantially larger change, since you'd now be
>>>> relocating nearly every remaining driver, i.e. all the
>>>> relatively modern 100M and GigE drivers.
>>>
>>
>> I am not particularly a fan of making a "legacy" directory and moving
>> old drivers into it.  Just because this is very subjective, if you say
>> "drivers which are X years old and not used much" is vague and depending
>> on who you ask would get varying results.  But if you were to were to
>> define legacy as all ISA, EISA and MCA drivers (not based on their use)
>> would be better.
>
> I think that being subjective can be an advantage.  There may
> be some debate on whether X is legacy or not, but I see no harm
> in that.  On the other hand, I see binding ourselves to concrete
> inflexible rules as a disadvantage.
>

I am not disagreeing that we need to be flexible, and to organize the
directory structure in a logical way does not equate to "concrete and
inflexible".

I brought the topic of organizing the /drivers/net directory up at
NetConf/Plumbers and here is what came about the discussion...

Joe and I are working to organize the drivers into
/drivers/net/<technology> directories and to cleanup the Kconfig to
reflect the organization.  Ethernet drivers will be in
/drivers/net/ethernet, and so on.  I brought up your suggestion to
making a "legacy" directory and those present did not like the idea.
In short, there is no advantage to this type of organization and
having the drivers reside in their current location or in the model of
/drivers/net/<technology> does not cause any problems

> For example, look at the sister directory, drivers/serial -- the
> venerable 8250 UART continues to support ISA-like mapped 0x3f8/0x2f8
> PIO devices such as those on the ISA MultiIO/IDE cards first appearing
> in 80286 computers.  But we probably don't want to shuffle that off to
> a legacy dir, given that nearly every embedded CPU manufacturer has a
> SoC 8250 UART implementation of their own, and it remains in high use.
>
>>
>> But if a legacy directory was to be made, I like Joe's suggestion of
>> drivers/net/ethernet/legacy.
>
> If we extend that to being a rule, i.e. drivers/net/*/legacy
> then we'd implicitly be advocating creation of things like:
>
>        drivers/net/tokenring/legacy
>        drivers/net/arcnet/legacy
>
> Yes, I do imagine you aren't suggesting we do that.  :)
>
>>
>>> Files to not need immediate renames.
>>>
>>> Renames could happen when the appropriate maintainer
>>> wants to or gets coerced to conform to some new
>>> file layout standard.
>>>
>>> I had submitted a related RFC patch:
>>>
>>> https://patchwork.kernel.org/patch/244641/
>>>
>>> and then had some off list discussions
>>> with Jeff Kirsher from Intel.
>>>
>>> Perhaps Jeff will chime in.
>>>
>>>> Plus what do you
>>>> do with the sb1000 - create drivers/cablemodem/legacy
>>>> just for one file?
>>>
>>> I never looked at that particular driver before.
>>> Maybe.  I don't have a strong opinion.  Leaving
>>> it where it is might be OK.
>>>
>>>> Or the ethernet drivers already in
>>>> existing subdirs, like arm and pcmcia -- do we move those?
>>>
>>> Maybe.  If there's no demand, there's no absolute need to
>>> move it at all.  I think a reasonable goal is to have some
>>> sensible and consistent file layout scheme though.
>>>
>>> There are arch specific directories under various drivers/...
>>> so I don't see a need to move directories like drivers/net/arm
>>> or drivers/s390.
>>
>> I agree with Joe.
>
> I don't think there is any disagreement here on this point.
> Moving stuff that is already in an appropriate subdir was
> never part of what I was proposing with drivers/legacy.
>
> But if we create subdirs with concrete definitions, then
> people will most likely be expecting all drivers that match
> to be in that specific subdir.

Correct, although I would use "logical organization" versus "concrete
definitions" and we are working on patches to do the clean up so that
Ethernet drivers are under /drivers/net/ethernet/*, as well as the
other technologies.  For the drivers like vlan, 8021q, bridging, etc
we will place those in /drivers/net/sw/.  That is the plan at least...

>
>>
>>>
>>>> With this, I tried to aim for a significant gain (close to 1/3
>>>> less files) within what I felt was a reasonable sized change
>>>> set that had a chance of getting an overall OK from folks.
>>>> Giant "flag-day" type mammoth changesets are a PITA for all.
>>>
>>> I believe there's no need for a flag-day.
>>> File renames could happen gradually or not at all.
>>>
>>>
>>
>> Again I agree with Joe.
>
> Sure, renames can be async, and driven by the individual
> maintainers of the files, but typically when conversion
> like events are left open ended (timewise) they tend
> to drag on for longer times than necessary.  At least in
> my experience.  If I had sent the RFC with one patch that
> amounted to a "mkdir", and no actual file moves, I wouldn't
> have expected much other than a bagful of scorn in return. :)
> Putting it to use and showing a real cleanup is where the
> value became really apparent, I think.
>

We are hoping not to drag this out and plan on getting this into
2.6.38 (net-next) within the couple of weeks.

> In any case, I still think this is worthwhile, and in the
> absence of an alternate proposal that gets a higher level
> of universal agreement, I'm hoping we can still do this.
> I've got a follow on commit ready that factors a lot of
> the legacy related probe code out of Space.c too.
>
> Regardless of which way it goes, thanks for the feedback.
> Paul.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists