On Tue, Mar 12, 2013 at 1:36 PM, Luis R. Rodriguez <rodrigue@xxxxxxxxxxxxxxxx> wrote: > On Tue, Mar 12, 2013 at 02:12:15PM +0200, Ozan Çağlayan wrote: >> > I read this thread when I got back from the mountains and agreed with >> > Hauke's recommendation. >> > >> > Luis >> >> Can you clarify what does $BT, BT=True achieve? It looks like it was >> some kind of switch to enable/disable BT but I can't be sure. > > Yeah that's legacy junk, nuke it at your liking. > >> On the other part, Hauke first suggested a different thing and then another >> way. > > I think the concern was to not build everything on the stock > vanilla release. > >> Should we enable all by default and --disable the unwanted ones or >> should we disable and print a usage by default and add --enable >> switches to enable subsystems? > > How about something very simple: > > * Enable all by default > > * Use Kconfig to allow us to select 4 subsystems: > - Ethernet > - WiFi > - Bluetooth > - DRM > > This way we'd keep the logic easy for an initial implementation > to support Kconfig (scripts/kconfig/mconf.c) and then build on > top of it to expand specifics. But I think I get the issue you were pointing out though -- its not about the building you are concerned about separating, its about the admin work of fixing patches that might be broken for other subystems. You want the option to say you don't care about a subsystem at admin-update time. Is that right? Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
