Re: suggested patch for prompting for kernel version instead of using a static list

[Stefan Hallas Andersen <stefande at cisco dot com>]

Hi Yann,

I understand your reasoning in having a known list of "supported"
kernels, but I also think flexibility/scalability is important and
giving the ability to deploy this in as many environments as in any way
possible.

Crosstool-ng already provides a quite broad set of sample configurations
which have always worked for me. I just think it's easier to understand
that if I change a config option from it's default value it might break
something than it not being available.

Using the pre-existing set of headers doesn't work well for what I'm
using this tool for, either I'd have to write a wrapping makefile around
crosstool taking care of preparation of the kernel headers or I'd have
to instruct people in how to do so. Also, I like that kernel header
preparation is part of this tool, it makes sense.

I really like you're idea of doing this through the kernel "drop down
list", of course protected by experimental.

Just my .10$

Best regards,
Stefan Hallas Andersen
Cisco Systems Inc.

On Wed, 2009-04-01 at 13:02 -0700, Yann E. MORIN wrote:
> Stefan,
> All,
> 
> On Wednesday 01 April 2009 19:32:36 Stefan Hallas Andersen wrote:
> > Attached is a patch to crosstool-ng v.1.3.2 which will prompt for a
> > kernel version to be used instead of a static list,
> 
> The 1.3 series will not have new features added: it is in maintenance
> only
> and gets only bugfixes.
> 
> New features are added on /trunk, and once that is ready, a branch for
> the new series will be created, and in its turn will get only
> bug-fixes,
> while new features get again added to /trunk.
> 
> And /trunk has much more kernel versions available than the /old/ 1.3
> branch.
> 
> 
> Now, feature-wise, prompting for the version as a string rather than
> as a list makes the kernel menu different from the other components,
> unless all components are migrated to this.
> 
> It also means crostool-NG can no longer offer a comprehensive patchset
> for each supported version of each component. At least, it makes it
> harder to maintain...
> 
> Also, it is error-prone, as the user can make a typo while entering
> the
> version string.
> 
> Know also, that you can direct crosstool-NG to using a pre-existing
> set of headers by using the option KERNEL_LINUX_USE_CUSTOM_DIR (in the
> 1.3 series), and KERNEL_LINUX_USE_CUSTOM_HEADERS (in trunk).
> 
> On the other hand, we can add an entry to the version list that would
> allow the user to enter the version as a string, but that would be
> correctly protected behind EXPERIMENTAL, so that the user is informed
> he/she's at risk when not using the available versions from the list.
> 
> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___
> |
> | --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/
> There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
> conspiracy.  |
> `------------------------------^-------^------------------^--------------------'
> 
> 
> 

--
For unsubscribe information see http://sourceware.org/lists.html#faq