mm: cma: Contiguous Memory Allocator added
in [Kernel]
|
From: Daniel Walker on 21 Jul 2010 15:00 On Wed, 2010-07-21 at 20:38 +0200, Michał Nazarewicz wrote: > > On Wed, 2010-07-21 at 20:11 +0200, Michał Nazarewicz wrote: > >> Not really. This will probably be used mostly on embedded systems > >> where users don't have much to say as far as hardware included on the > >> platform is concerned, etc. Once a phone, tablet, etc. is released > >> users will have little need for customising those strings. > > On Wed, 21 Jul 2010 20:19:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > > You can't assume that user won't want to reflash their own kernel on the > > device. Your assuming way too much. > > If user is clever enough to reflash a phone she will find the strings > easy especially that they are provided from: (i) bootloader which is > even less likely to be reflashed and if someone do reflash bootloader > she is a guru who'd know how to make the strings; or (ii) platform > defaults which will be available with the rest of the source code > for the platform. Your, again, assuming all sorts of stuff .. On my phone for example it is very easy to reflash, personally, I think most devices will be like that in the future. so you don't _need_ to be clever to reflash the device. > > If you assume they do want their own kernel then they would need this > > string from someplace. If your right and this wouldn't need to change, > > why bother allowing it to be configured at all ? > > Imagine a developer who needs to recompile the kernel and reflash the > device each time she wants to change the configuration... Command line > arguments seems a better option for development. So make it a default off debug configuration option .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 21 Jul 2010 15:30 On Wed, 21 Jul 2010 20:58:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > On Wed, 2010-07-21 at 20:38 +0200, Michał Nazarewicz wrote: >> > On Wed, 2010-07-21 at 20:11 +0200, Michał Nazarewicz wrote: >> >> Not really. This will probably be used mostly on embedded systems >> >> where users don't have much to say as far as hardware included on the >> >> platform is concerned, etc. Once a phone, tablet, etc. is released >> >> users will have little need for customising those strings. >> >> On Wed, 21 Jul 2010 20:19:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: >> > You can't assume that user won't want to reflash their own kernel on the >> > device. Your assuming way too much. >> >> If user is clever enough to reflash a phone she will find the strings >> easy especially that they are provided from: (i) bootloader which is >> even less likely to be reflashed and if someone do reflash bootloader >> she is a guru who'd know how to make the strings; or (ii) platform >> defaults which will be available with the rest of the source code >> for the platform. > > Your, again, assuming all sorts of stuff .. On my phone for example it > is very easy to reflash, personally, I think most devices will be like > that in the future. so you don't _need_ to be clever to reflash the > device. Bottom line is: if you reflash the device you (i) get an image from somewhere and it has the strings in it, (ii) reflash the kernel and parameters are provided by bootloader so they still remain, (iii) use platform default strings which you get with the source codes and include when kernel is built, or (iv) are a guru who knows what to do. >> > If you assume they do want their own kernel then they would need this >> > string from someplace. If your right and this wouldn't need to change, >> > why bother allowing it to be configured at all ? >> >> Imagine a developer who needs to recompile the kernel and reflash the >> device each time she wants to change the configuration... Command line >> arguments seems a better option for development. > > So make it a default off debug configuration option .. I don't really see the point of doing that. Adding the command line parameters is really a minor cost so there will be no benefits from removing it. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 21 Jul 2010 15:40 On Wed, 2010-07-21 at 21:21 +0200, Michał Nazarewicz wrote: > On Wed, 21 Jul 2010 20:58:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > > > On Wed, 2010-07-21 at 20:38 +0200, Michał Nazarewicz wrote: > >> > On Wed, 2010-07-21 at 20:11 +0200, Michał Nazarewicz wrote: > >> >> Not really. This will probably be used mostly on embedded systems > >> >> where users don't have much to say as far as hardware included on the > >> >> platform is concerned, etc. Once a phone, tablet, etc. is released > >> >> users will have little need for customising those strings. > >> > >> On Wed, 21 Jul 2010 20:19:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > >> > You can't assume that user won't want to reflash their own kernel on the > >> > device. Your assuming way too much. > >> > >> If user is clever enough to reflash a phone she will find the strings > >> easy especially that they are provided from: (i) bootloader which is > >> even less likely to be reflashed and if someone do reflash bootloader > >> she is a guru who'd know how to make the strings; or (ii) platform > >> defaults which will be available with the rest of the source code > >> for the platform. > > > > Your, again, assuming all sorts of stuff .. On my phone for example it > > is very easy to reflash, personally, I think most devices will be like > > that in the future. so you don't _need_ to be clever to reflash the > > device. > > Bottom line is: if you reflash the device you (i) get an image from > somewhere and it has the strings in it, (ii) reflash the kernel and > parameters are provided by bootloader so they still remain, (iii) > use platform default strings which you get with the source codes and > include when kernel is built, or (iv) are a guru who knows what to > do. What makes you assume that the bootloader would have these strings? Do your devices have these strings? Maybe mine don't have them. Assume the strings are gone and you can't find them, or have no idea what they should be. What do you do then? > >> > If you assume they do want their own kernel then they would need this > >> > string from someplace. If your right and this wouldn't need to change, > >> > why bother allowing it to be configured at all ? > >> > >> Imagine a developer who needs to recompile the kernel and reflash the > >> device each time she wants to change the configuration... Command line > >> arguments seems a better option for development. > > > > So make it a default off debug configuration option .. > > I don't really see the point of doing that. Adding the command line > parameters is really a minor cost so there will be no benefits from > removing it. Well, I like my kernel minus bloat so that's a good reason. I don't see a good reason to keep the interface in a production situation .. Maybe during development , but really I don't see even a developer needing to make the kind of changes your suggesting very often. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 21 Jul 2010 16:00 On Wed, 21 Jul 2010 21:37:09 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > What makes you assume that the bootloader would have these strings? > Do your devices have these strings? Maybe mine don't have them. I don't assume. I only state it as one of the possibilities. > Assume the strings are gone and you can't find them, or have no idea > what they should be. What do you do then? Ask Google? I have a better question for you though: assume the "mem" parameter is lost and you have no idea what it should be? There are many parameters passed to kernel by bootloader and you could ask about all of them. Passing cma configuration via command line is one of the possibilities -- especially convenient during development -- but I would expect platform defaults in a final product so you may well not need to worry about it. Bottom line: if you destroyed your device, you are screwed. >>>> Imagine a developer who needs to recompile the kernel and reflash the >>>> device each time she wants to change the configuration... Command line >>>> arguments seems a better option for development. >>> So make it a default off debug configuration option .. >> I don't really see the point of doing that. Adding the command line >> parameters is really a minor cost so there will be no benefits from >> removing it. > Well, I like my kernel minus bloat so that's a good reason. I don't see > a good reason to keep the interface in a production situation .. Maybe > during development , but really I don't see even a developer needing to > make the kind of changes your suggesting very often. As I've said, removing the command line parameters would not benefit the kernel that much. It's like 1% of the code or less. On the other hand, it would add complexity to the CMA framework which is a good reason not to do that. Would you also argue about removing all the other kernel parameters as well? I bet you don't use most of them. Still they are there because removing them would add too much complexity to the code (conditional compilation, etc.). I'm not saying that removing “bloat” (or unused options if you will) from the kernel is a bad thing but there is a line where costs of doing so negate the benefits. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 21 Jul 2010 16:10
On Wed, 2010-07-21 at 21:53 +0200, Michał Nazarewicz wrote: > On Wed, 21 Jul 2010 21:37:09 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > > What makes you assume that the bootloader would have these strings? > > Do your devices have these strings? Maybe mine don't have them. > > I don't assume. I only state it as one of the possibilities. > > > Assume the strings are gone and you can't find them, or have no idea > > what they should be. What do you do then? > > Ask Google? Exactly, that's why they need to be in the kernel .. > I have a better question for you though: assume the "mem" parameter is > lost and you have no idea what it should be? There are many parameters > passed to kernel by bootloader and you could ask about all of them. That's hardware based tho. Of course you need info on what your hardware is. What your doing isn't based on hardware specifics, it's based on optimizations. > Passing cma configuration via command line is one of the possibilities > -- especially convenient during development -- but I would expect platform > defaults in a final product so you may well not need to worry about it. I honestly don't thing the "development" angle flies either , but if you keep this there's no way it should be enabled for anything but debug. > > Well, I like my kernel minus bloat so that's a good reason. I don't see > > a good reason to keep the interface in a production situation .. Maybe > > during development , but really I don't see even a developer needing to > > make the kind of changes your suggesting very often. > > As I've said, removing the command line parameters would not benefit the > kernel that much. It's like 1% of the code or less. On the other hand, > it would add complexity to the CMA framework which is a good reason not > to do that. If we allowed everyone to add there little tiny bit of bloat where would we be? > Would you also argue about removing all the other kernel parameters as > well? I bet you don't use most of them. Still they are there because > removing them would add too much complexity to the code (conditional > compilation, etc.). Your is at a different level of complexity .. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |