Patchwork kernel/linux: Allow user to manually enter Linux version

login
register
mail settings
Submitter ANDY KENNEDY
Date Jan. 3, 2013, 6:20 p.m.
Message ID <F9C551623D2CBB4C9488801D14F864C610B989AC@ex-mb1.corp.adtran.com>
Download mbox | patch
Permalink /patch/209294/
State Rejected
Headers show

Comments

ANDY KENNEDY - Jan. 3, 2013, 6:20 p.m.
In addition to the choice list and the custom version, allow the user to
enter a free format version to pull from kernel.org (or the specified
local repo) as a standard version number.

Signed-off-by: "Andy Kennedy" <andy.kennedy@adtran.com>

---

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Jan. 7, 2013, 5:49 p.m.
Andy, All,

On Thursday 03 January 2013 ANDY KENNEDY wrote:
> In addition to the choice list and the custom version, allow the user to
> enter a free format version to pull from kernel.org (or the specified
> local repo) as a standard version number.

If you need a custom version (ie a version not in the list) of any
component, then the "custom location" option is exactly here for this.
You just have to extract your kernel yourself, and point ct-ng at the
directory you extracted your kernel in..

We used to have a "custom version" (version, as 'version string') option
for some components (eg. uClibc), but those have been all changed to use
the common "custom location" infrastructure.

Basically, from the point-of-view of crosstool-NG, there is absolutely no
difference whatsoever between:
  - using a version that is not in the list,
  - using a completely custom source tree.

In both cases, it means that you want to use something that is alien to
crosstool-NG, so there is no reason to differentiate those cases.

The only slight advantage would be to use crosstool-NG's internal function
to do the download-extract-patch, but thtat is sufficiently trivial to
either do manually, or implement in a driver script.

Regards,
Yann E. MORIN.
ANDY KENNEDY - Jan. 7, 2013, 9:08 p.m.
> -----Original Message-----
> From: Yann E. MORIN [mailto:yann.morin.1998@gmail.com] On Behalf Of Yann E. MORIN
> Sent: Monday, January 07, 2013 11:50 AM
> To: crossgcc@sourceware.org
> Cc: ANDY KENNEDY
> Subject: Re: [PATCH] kernel/linux: Allow user to manually enter Linux version
> 
> Andy, All,
> 
> On Thursday 03 January 2013 ANDY KENNEDY wrote:
> > In addition to the choice list and the custom version, allow the user to
> > enter a free format version to pull from kernel.org (or the specified
> > local repo) as a standard version number.
> 
> If you need a custom version (ie a version not in the list) of any
> component, then the "custom location" option is exactly here for this.
> You just have to extract your kernel yourself, and point ct-ng at the
> directory you extracted your kernel in..
> 
> We used to have a "custom version" (version, as 'version string') option
> for some components (eg. uClibc), but those have been all changed to use
> the common "custom location" infrastructure.
> 
> Basically, from the point-of-view of crosstool-NG, there is absolutely no
> difference whatsoever between:
>   - using a version that is not in the list,
>   - using a completely custom source tree.
> 
> In both cases, it means that you want to use something that is alien to
> crosstool-NG, so there is no reason to differentiate those cases.
> 
> The only slight advantage would be to use crosstool-NG's internal function
> to do the download-extract-patch, but thtat is sufficiently trivial to
> either do manually, or implement in a driver script.

That is the advantage I was going for ;).

Please forgive the ignorance, but was is a driver script?  I see nothing
with -i "driver script" in the docs directory.  Could you explain to me
the "right way" of doing what I'm attempting?  I'd rather use your tool
the way you intend it that to have to maintain this patch locally, however,
I don't mind doing that for the ease of use the patch offers.

Thanks Yann!

Andy

> 
> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  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
Yann E. MORIN - Jan. 7, 2013, 9:28 p.m.
Andy, All,

On Monday 07 January 2013 ANDY KENNEDY wrote:
> Please forgive the ignorance, but was is a driver script?

Oh, sure! :-)
A simple driver script could be something like:

---8<---
#!/bin/sh
# Call this script something witty, eg.: my-ct-ng  ;-)
set -e

KVER="X.Y.Z"
KDIR="linux-${KVER}"
KFILE="${KDIR}.tar.bz2"
KURL="http://kernel.org/pub/..../${KFILE}"

if [ ! -f "${KDIR}" ]; then
    if [ ! -f "${KFILE}" ]; then
        curl "${KURL}" >"${KFILE}"
    fi
    tar xjf "${KFILE}"
fi

exec ct-ng "${@}"
---8<---

Well, totally untested. You can refine to your case (eg. git clone +
git checkout instead of curl...), but you get the idea.

In this case, you're using ct-ng as a "backend" for your real build system,
which in this case is your very, very minimalist "my-ct-ng" script.

Hence, we call this script a "driver", because it "drives" a sub-process
(here ct-ng), that is it prepares the environment, or some dirs/files...
prior to running the actual program.

That's exactly what "gcc" (the command) is: it is a compiler driver, that
parses its arguments to see how it was called, and what sub-process it
should call: actuall C compiler (cc1), C++ compiler (cc1plus), linker (ld)
and so on...

No, it's not in ct-ng's documentation, because it is not specific to
ct-ng. It is a usually-accepted term (I guess). Sometime also referred
to as a frontend, but it is does convey a different, although somewhat
related. meaning.

Regards,
Yann E. MORIN.
ANDY KENNEDY - Jan. 7, 2013, 9:33 p.m.
> -----Original Message-----
> From: Yann E. MORIN [mailto:yann.morin.1998@gmail.com] On Behalf Of Yann E. MORIN
> Sent: Monday, January 07, 2013 3:28 PM
> To: crossgcc@sourceware.org
> Cc: ANDY KENNEDY
> Subject: Re: [PATCH] kernel/linux: Allow user to manually enter Linux version
> 
> Andy, All,
> 
> On Monday 07 January 2013 ANDY KENNEDY wrote:
> > Please forgive the ignorance, but was is a driver script?
> 
> Oh, sure! :-)
> A simple driver script could be something like:
> 
> ---8<---
> #!/bin/sh
> # Call this script something witty, eg.: my-ct-ng  ;-)
> set -e
> 
> KVER="X.Y.Z"
> KDIR="linux-${KVER}"
> KFILE="${KDIR}.tar.bz2"
> KURL="http://kernel.org/pub/..../${KFILE}"
> 
> if [ ! -f "${KDIR}" ]; then
>     if [ ! -f "${KFILE}" ]; then
>         curl "${KURL}" >"${KFILE}"
>     fi
>     tar xjf "${KFILE}"
> fi
> 
> exec ct-ng "${@}"
> ---8<---
> 
> Well, totally untested. You can refine to your case (eg. git clone +
> git checkout instead of curl...), but you get the idea.
> 
> In this case, you're using ct-ng as a "backend" for your real build system,
> which in this case is your very, very minimalist "my-ct-ng" script.
> 
> Hence, we call this script a "driver", because it "drives" a sub-process
> (here ct-ng), that is it prepares the environment, or some dirs/files...
> prior to running the actual program.
> 
> That's exactly what "gcc" (the command) is: it is a compiler driver, that
> parses its arguments to see how it was called, and what sub-process it
> should call: actuall C compiler (cc1), C++ compiler (cc1plus), linker (ld)
> and so on...
> 
> No, it's not in ct-ng's documentation, because it is not specific to
> ct-ng. It is a usually-accepted term (I guess). Sometime also referred
> to as a frontend, but it is does convey a different, although somewhat
> related. meaning.

I refer to that as a wrapper, myself, but I'll attempt to record your
terminology in the noggin' for later use.

So, I have the choice to:
	1) maintain my own patch
	2) generate and maintain my own Linux kernel downloader/unpacker/etc.

I guess I'll go with the patch technique.

Thanks again!

Andy

> 
> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  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

Patch

diff -Naur a/config/kernel/linux.in b/config/kernel/linux.in
--- a/config/kernel/linux.in    2013-01-03 12:11:45.000000000 -0600
+++ b/config/kernel/linux.in    2013-01-03 12:13:11.000000000 -0600
@@ -127,6 +127,20 @@ 
       It is now maintained by Greg Kroah-Hartman, see this mailing list entry:
         http://marc.info/?l=linux-kernel&m=129133701916793&w=4

+config KERNEL_MANUAL
+    bool
+    prompt "Manually provide the kernel version."
+    help
+      Specify the exact kernel version you wish to use.
+
+config KERNEL_MANUAL_VER
+    string
+    prompt "Enter the kernel version"
+    depends on KERNEL_MANUAL
+    help
+      The version should be entered as 2.6.33 or 2.6.36.2 etc.  Do not provide
+      linux- before or .tar.bz2 after.
+
 config KERNEL_LINUX_CUSTOM
     bool
     prompt "custom tarball or directory"
@@ -163,6 +177,7 @@ 
     default "2.6.32.60" if KERNEL_V_2_6_32_60
     default "2.6.31.14" if KERNEL_V_2_6_31_14
     default "2.6.27.62" if KERNEL_V_2_6_27_62
+    default KERNEL_MANUAL_VER if KERNEL_MANUAL
     default "custom" if KERNEL_LINUX_CUSTOM

 endif # ! KERNEL_LINUX_USE_CUSTOM_HEADERS