Hello Do we consider below 2 options? -- DriversPkg/Vendor/<VendorName>/Bus/<BusType> ? or -- DriversPkg/Bus/<BusType>/Vendor/<VendorName> ?
Another option is that we add <DriverCategory>, like GOP/UNDI/RAID/SIO. Then we can put UNDI driver together, no matter it is PCI based or USB based. Thank you Yao Jiewen -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Friday, July 31, 2015 6:17 AM To: Kinney, Michael D; Leif Lindholm; Kinney, Michael D Cc: edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support On 2015-07-30 11:51:56, Kinney, Michael D wrote: > Jordan, > > I agree with the concept of having package(s) for device driver content. > > OptionRomPkg is really only intended to provide good examples for > writing drivers, and we want to restrict what goes in there to a good > example for each driver type. Thus, if we have good example drivers in DriversPkg, then OptionRomPkg is not needed? :) > So I do not think OptionRomPkg is a good landing zone for this type of > content. > > I think the hardest part is deciding how to organizer the driver > content in package(s)/directories. Some device vendors may prefer to > have vendor specific package/directory names to store families of > drivers. Other vendors may be fine with putting their driver in a > common package. > > The other part that may cause some confusion is that we already have > drivers for some controllers in existing packages so finding the > drivers already requires looking in multiple packages. Those drivers > tend to be based on industry standard register sets (i.e. UHCI, EHCI, > SATA, USB, etc). > > If we want to follow dir structure that matches what we have done in > MdeModulePkg for industry standard host controllers, buses, and > devices and support vendor specific areas, maybe we can do something > like the following: > > DriversPkg > DriversPkg/Vendor/<VendorName> > DriversPkg/Bus/<BusType> Would we expect this too? DriversPkg/Vendor/<VendorName>/Bus/<BusType> I'm not sure how necessary the 'Vendor' directory level is. Seems fine though. -Jordan > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Leif Lindholm > Sent: Thursday, July 30, 2015 8:20 AM > To: Justen, Jordan L > Cc: Kinney, Michael D; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet > support > > Hi Jordan, > > On Wed, Jul 29, 2015 at 02:59:04PM -0700, Jordan Justen wrote: > > > > But, the name 'open platform' also sounds strange, assuming this > > > > a plain PCI bus driver. Couldn't it live in a 'pci drivers' package? > > > > > > > > Personally, I think we should rename OptionRomPkg to DriversPkg, > > > > or split it into UsbDriversPkg and PciDriversPkg. > > > > This seems like another thing we've been talking about for years. :) > > > > What do you think about adding: > > > > DriversPkg > > DriversPkg/Pci > > DriversPkg/Usb > > > > or > > > > PciDriversPkg > > UsbDriversPkg > > <bikeshed> > We may well need support for drivers (read: I already have) that are > neither USB nor PCI. Should connecting interface still be the primary > filter? > </bikeshed> > > > One possible concern is who will own/maintain such a package. In > > this case, it might make sense to have a separate Maintainers.txt > > file under the package. > > > > Or, what I would suggest is that we just start out by saying that > > edk2-devel collectively owns it, and that any other package > > maintainer can commit contributions to the package. > > I think that is a sensible thing to do until there is sufficient > amount of code in there to require a dedicated (set of) maintainer(s). > > What about platform code? > > / > Leif > > > > So, OpenPlatformPkg is my current way of dealing with the lack of > > > a unified handling of platform/driver code in edk2. It is not > > > something I mind giving up if this situation resolves itself > > > another way. Or renaming to something more palatable :) > > > > > > I gave a presentation (more like lightning talk) at the spring > > > plugfest in Seattle on this: > > > http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Pl > > > atforms_Tree_May_2015.pdf > > > > > > If we simply rename OptionRomPkg to DriversPkg (and restructure a > > > bit in there), then that solves the drivers part of my problem. > > > But I still need something for opensource platform support. > > > > > > / > > > Leif > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
