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
| ||
|
Message-ID: <Pine.LNX.4.44L0.1202251033550.4173-100000@netrider.rowland.org> Date: Sat, 25 Feb 2012 10:46:53 -0500 (EST) From: Alan Stern <stern@...land.harvard.edu> To: Arnd Bergmann <arnd@...db.de> cc: Wolfram Sang <w.sang@...gutronix.de>, <linux-arm-kernel@...ts.infradead.org>, Roland Stigge <stigge@...com.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <kevin.wells@....com> Subject: Re: [PATCH v2] USB: Support for LPC32xx SoC On Sat, 25 Feb 2012, Arnd Bergmann wrote: > On Saturday 25 February 2012, Wolfram Sang wrote: > > > Unfortunately, the way that ohci handles the abstraction between the > > > various implementations is backwards, it would be much easier if the > > > main driver was following that model to start with. > > > > ... exactly for that reason I didn't suggest it. Looking at other ohci-sources > > (e.g. ohci-omap.c), machine_is_* seems to be the consistent use-case. > > I still hope that someone takes the time to convert ohci and ehci into > something more regular, building the .c files separately instead of the > conditional #include "foo.c" inside of the main file. > > Alan and Greg, do you know if anyone is working on that, and if not do you > think someone should do it? You are talking about two separate issues. One is the way the various bus-glue files get built into the driver, and the other is the way it #includes .c files. I don't view the second as a big deal. A few people have complained about it, but I don't see the point. Sure, it has the disadvantage that you have to recompile the entire driver any time one of the files is changed. I can live with that. It has the advantage that symbols shared among the source files can be static; they don't have to get merged into the overall kernel namespace when the driver isn't build as a module. The first issue is more serious. There are long-term plans to restructure both of those drivers so that the bus glue resides in a separate module from the main core of the driver. However I have not started to work on that yet; there are other more pressing matters to do first. It doesn't seem extremely urgent. Things are working the way they are. The main advantage to restructuring is that it would allow distributors to build bus glue for multiple platforms in a single distribution image. Currently that's not possible (except that any one of the platform glues can be enabled along with the PCI glue). A little progress has been made already. We just received a submission for a "generic" platform bus glue file that will be able to take over the jobs of several of the existiing files. If anyone wants to take this further I won't object, but I don't plan to work on it myself soon. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists