lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 05 Nov 2010 08:51:20 -0400 From: Paul Gortmaker <paul.gortmaker@...driver.com> To: Jeff Kirsher <jeffrey.t.kirsher@...el.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 10-11-04 10:28 PM, Jeff Kirsher wrote: > 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... Thanks for the update, I wasn't aware that happened. > > 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. Interesting. I would have not came to that conclusion based on the feedback on netdev@...r alone. Oh well, if that was the consensus then I'm not going to argue with it. > 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 [...] >>>> >>>> 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 If you do get agreement on subcategories under ethernet for one reason or another (i.e. vendor grouping), then I'd suggest using ns8390 as a grouping category - it would lend itself well to coalescing a lot of legacy drivers in itself. > 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. Sounds good. In the end, the one thing I was hoping to see happen was a bit more organization in drivers/net - and both solutions should be able to provide this. Paul. > >> 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 >> > > > -- 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