[Fuego] [PATCH] Dockerfile: Install linux-headers
Tim.Bird at sony.com
Tim.Bird at sony.com
Mon Jan 29 20:03:58 UTC 2018
> -----Original Message-----
> From: Hoang Van Tuyen [mailto:tuyen.hoangvan at toshiba-tsdv.com]
> Sent: Sunday, January 28, 2018 6:55 PM
> To: Bird, Timothy <Tim.Bird at sony.com>; fuego at lists.linuxfoundation.org
> Subject: Re: [Fuego] [PATCH] Dockerfile: Install linux-headers
> Hello Tim,
> Sorry!. It seems that I have not got your point in your comment.
> I have more explanation in the below.
> >> -----Original Message-----
> >> From: Hoang Van Tuyen on Wednesday, January 24, 2018 5:45 PM
> >> In the backfire test of the rt-tests, We need linux-headers for
> >> building the backfire driver.
> >> Signed-off-by: Hoang Van Tuyen <tuyen.hoangvan at toshiba-tsdv.com>
> >> ---
> >> Dockerfile | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> diff --git a/Dockerfile b/Dockerfile
> >> index 450ace3..a3cf8a9 100644
> >> --- a/Dockerfile
> >> +++ b/Dockerfile
> >> @@ -31,7 +31,7 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get
> >> update &&
> >> apt-get -yV install \
> >> inotify-tools g++ bzip2 bc libaio-dev gettext pkg-config
> >> libglib2.0-dev \
> >> time python-pip python-xmltodict at minicom lzop bsdmainutils
> >> u-boot-tools \
> >> mc netcat lava-tool openssh-server python-parsedatetime \
> >> - libsdl1.2-dev libcairo2-dev libxmu-dev libxmuu-dev
> >> + libsdl1.2-dev libcairo2-dev libxmu-dev libxmuu-dev
> >> linux-headers-$(uname -r)
> > I'm not liking this much. the $(uname -r) is coming from the host
> > maching where the docker image was created. Admittedly it will
> > very likely be x86_64, but who knows what kernel version it will be.
> I think $(uname -m) will be return x86_64, but $(uname -r) will be print
> kernel release (3.16.0-4-amd64).
You’re right. 'uname -r' doesn't include the architecture. I conflated
these two issues.
The overall issue is that the host may not have the same kernel version
as the target. Since we load the Linux header files for the Debian version
that's in the docker container, it's even more weird.
> It is proper for installing the Linux header file.
> This installing is used if target machine is docker machine. For the
> other machines,
> We need a toolchain/SDK for the machine with Linux header was installed
> in the
Yes. That's correct. I didn't realize this was only used for a docker target.
In any event, the situation is still not good.
We would like to be able to build a docker image that will work on other
machines. That is, we'd like to create a docker image on one machine
(maybe on mine, as the main Fuego maintainer), and have it be possible
for people to use that container on their Fuego host. In this case,
the Linux-headers on the machine where the container was created
will likely not match the kernel version on the machine where the
container is executed.
In the long run, we want to move installation of the SDK for the
docker container, to a post-container-creation step. That is,
we'd separate those packages out, and do some kind of install
script that could be used on the container after it's placed on
some user's host.
> I think, in the fuego_test.sh, we should have a pre_check that the Linux
> exists on the SDK or not.
> How do you think about this?
This would be a good solution. It would be better than restricting
the test to just x86_64. We can do this now in the test, and decide
how to isolate the SDK installation for the 'docker' board separately.
> Best regards,
> > It's in unlikely, IMO, that the kernel version of the host will match
> > the kernel version of the target board.
> > This won't matter for a test like 'backfire', but for something else,
> > this could be important.
> > In the long term, I'd like to separate out some of these packages
> > into a separate 'install x86_64 toolchain' step. I believe the patches
> > from profusion are starting some changes to Dockerfile in this direction.
> >> RUN pip install python-jenkins==0.4.14
> >> RUN pip install filelock
> >> --
> >> 2.1.4
> > Sorry but NAK on this one.
> > Let's have a discussion to decide how to best re-do the toolchain/SDK
> > for x86_64, so it doesn't have the problems mentioned above.
> > -- Tim
> Hoang Van Tuyen (Mr.)
> TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD.
> 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam
> Tel: 84-4-22208801 (Company) - Ext.251
> Fax: 84-4-22208802 (Company)
> Email: tuyen.hoangvan at toshiba-tsdv.com
> This mail was scanned by BitDefender
> For more information please visit http://www.bitdefender.com
More information about the Fuego