Date   

RFC - integrating target runtime information into a yocto build

Tim Bird <tim.bird@...>
 

Hi everyone,

I'm doing research on whole-system optimization, and I'd like to ask opinions
on the next stage of my work.

== background ==
After a fair amount of blood, sweat and tears, I have (finally) produced a working
ARM kernel that is optimized with gcc's link-time-optimization (LTO) feature.
Previously, I had completed a system that did syscall detection in object files,
and unused syscall elimination in the Linux kernel.

In the next stage of my research, I'm planning on combining those two
to do kernel optimization and rebuilding, AFTER the distribution image build.

There are a number of other techniques I'll be looking at as well, including
1) profiling applications and re-linking with modified linker scripts to increase
the locality of init-time functions (and reduce flash access during boot)
2) profiling block-layer accesses to convert portions of applications to XIP
using the AXFS filesystem
3) additional automated kernel feature elimination from whole-image static
and runtime analysis.

Finally (by way of background), I already have tools to automate the process
of installing software on the target, rebooting, running programs and
collecting results.

== questions ==
First, has anyone already done anything with OE or YP that takes data
from a running system, and feeds it back into the build system?

Does it make sense to add recipes to YP that wrap my tools, collect
the data and re-start the build process? Is this even possible?
That is, can bitbake wait for results from a late build stage,
invalidate previous results, and cause rebuilds of key components?
Or is this stretching things too far?

Has anyone built recipes in OE or YP for image deployment,
target control, or test execution?

The alternative is to put this iteration outside of the build process.
That is, to do an initial build, collect results, modify the build inputs,
and do a subsequent build (directed from "above" bitbake, rather than
from recipes inside the build system).

Does anyone have any experience with this? Any ideas on the best
approach?

I'm not expert enough in YP to know the dangers here.
I would, however, very much like to make this work reproducible
and automated, which is why I have a high interest in doing
this in YP.

Thanks,
-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: Inconsistency in the SDK

Patrick Turley <PatrickTurley@...>
 

On Jan 23, 2013, at 10:19 AM, "Zhang, Jessica" <jessica.zhang@...> wrote:

Please file a bug at bugzilla.yoctoproject.org
Done:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=3784

Thank you.


Re: Inconsistency in the SDK

Patrick Turley <PatrickTurley@...>
 

On Jan 23, 2013, at 10:21 AM, Khem Raj <raj.khem@...> wrote:

Did you source the env script before doing all that ?

Thank you for your question, but it doesn't apply.  All of this happens *before* I even tried to build anything.

The fundamental problem is that the SDK installation script puts the native sysroot in one directory, but the tool chain believes the default location for the native sysroot is in a *different* directory that doesn't exist.

On Wednesday, January 23, 2013, Patrick Turley <PatrickTurley@...> wrote:
> Here's our machine in local.conf:
>
>     MACHINE = "dm8148-mpu"
>
> Naturally, then, we see a directly like this under tmp/work:
>
>     dm8148_mpu-poky-linux-gnueabi
>
> Also, under tmp/sysroots, we see these two:
>
>     dm8148-mpu
>     dm8148-mpu-tcbootstrap
>
> Finally, when I install the SDK, I see the following under sysroots:
>
>     dm8148_mpu-poky-linux-gnueabi
>     x86_64-pokysdk-linux
>
> However, if I ask the cross-compiler the path to its default sysroot, I see this:
>
>     $ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux
>     $ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
>     $ ./arm-poky-linux-gnueabi-gcc -print-sysroot
>     /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
>
> There is no such directory. That is, the default sysroot for the SDK doesn't exist.
>
> Now, if I go back and look in tmp/work, I realize that I see *both* of these:
>
>     dm8148_mpu-poky-linux-gnueabi
>     armv7a-vfp-neon-poky-linux-gnueabi
>
> There are a number of work directories under both.
>
> It seems to me there are these possibilities:
>
>
> 1) There are at least two different (and disagreeing) methods to compute the architecture "tuple," and different pieces of the system are choosing different methods. These different methods usually agree, but sometimes they don't. Thus, when they *do* agree, it's "luck."
>
>
> 2) These strings *should* agree, but something is missing from our machine definition that causes them to disagree (we weren't using our own machine definition until recently). In that case, the machine definition code should change such that it's not *possible* for these strings to disagree. Also, I'd like to know what we missed, so we can fix it.
>
>
> 3) These strings, though similar, actually *mean* different things and are *both* correct. The only problem is that the build process for the tool chain chooses the wrong one when defining the default sysroot path.
>
>
> In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution.
>
> _______________________________________________
> yocto mailing list
> yocto@...
> https://lists.yoctoproject.org/listinfo/yocto
>


Re: are separate -sdk image targets necessary Was: Build external module against Yocto kernel

Burton, Ross <ross.burton@...>
 

On 23 January 2013 16:51, Trevor Woerner <twoerner@...> wrote:
On Tue, Jan 15, 2013 at 2:16 PM, Zhang, Jessica <jessica.zhang@...> wrote:
According to bug 1614, the kernel dev packages should be
included in sdk images. Please generate your toolchain using
"bitbake core-image-sato-sdk -c populate_sdk" which will
make the toolchain target sysroot matching your image's
sysroot (this is a new feature of 1.3) as long as your image
is a sdk image.
I am a bit confused by the above email. To me it appears as if Jessica
is saying: "add '-c populate_sdk' to the build of an -sdk image".

But if we look at this email from Mark Hatle:
http://www.mail-archive.com/yocto@yoctoproject.org/msg10636.html

I get the impression that Mark is saying: "now that '-c populate_sdk'
is available, there no longer is any need for separate -sdk images".

Am I confusing two different things with each other?
My understanding was that populate_sdk will take the package set from
an image, add compilers and all development packages, and produce a
SDK. So all you need is your production image, and then you can
generate a SDK from that.

Ross


are separate -sdk image targets necessary Was: Build external module against Yocto kernel

Trevor Woerner
 

On Tue, Jan 15, 2013 at 2:16 PM, Zhang, Jessica <jessica.zhang@...> wrote:
According to bug 1614, the kernel dev packages should be
included in sdk images. Please generate your toolchain using
"bitbake core-image-sato-sdk -c populate_sdk" which will
make the toolchain target sysroot matching your image's
sysroot (this is a new feature of 1.3) as long as your image
is a sdk image.
I am a bit confused by the above email. To me it appears as if Jessica
is saying: "add '-c populate_sdk' to the build of an -sdk image".

But if we look at this email from Mark Hatle:
http://www.mail-archive.com/yocto@yoctoproject.org/msg10636.html

I get the impression that Mark is saying: "now that '-c populate_sdk'
is available, there no longer is any need for separate -sdk images".

Am I confusing two different things with each other?


Re: SRC_URI checksums

Jerrod Peach <peachj@...>
 

On Wed, Jan 23, 2013 at 11:11 AM, Darren Hart <dvhart@...> wrote:
What is the practice for SRC_URI checksums? I see many recipes with both
md5sum and sha256sum. Is there a need to have both? Is one preferred
over the other?

Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

I believe bitbake/Yocto will complain at you if you don't have both, but I've always wondered this myself.  Since it's just an integrity check, I'd think an md5sum would be sufficient and marginally faster than a sha256, but if you wanted to be ultra paranoid, a sha256 would probably be good enough.  The level of paranoia it would take to want to make both checks is beyond what just about anyone would want, I'd suspect.  I'll append to the original e-mailer's question: Should the default be to require both checks?  Is there a simple way to turn off complaining about one check or the other if you're not interested in running both?  Are both even run?  (I think they both are...)

Kind regards,

Jerrod


Re: Inconsistency in the SDK

Khem Raj
 


Did you source the env script before doing all that ?


On Wednesday, January 23, 2013, Patrick Turley <PatrickTurley@...> wrote:
> Here's our machine in local.conf:
>
>     MACHINE = "dm8148-mpu"
>
> Naturally, then, we see a directly like this under tmp/work:
>
>     dm8148_mpu-poky-linux-gnueabi
>
> Also, under tmp/sysroots, we see these two:
>
>     dm8148-mpu
>     dm8148-mpu-tcbootstrap
>
> Finally, when I install the SDK, I see the following under sysroots:
>
>     dm8148_mpu-poky-linux-gnueabi
>     x86_64-pokysdk-linux
>
> However, if I ask the cross-compiler the path to its default sysroot, I see this:
>
>     $ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux
>     $ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
>     $ ./arm-poky-linux-gnueabi-gcc -print-sysroot
>     /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
>
> There is no such directory. That is, the default sysroot for the SDK doesn't exist.
>
> Now, if I go back and look in tmp/work, I realize that I see *both* of these:
>
>     dm8148_mpu-poky-linux-gnueabi
>     armv7a-vfp-neon-poky-linux-gnueabi
>
> There are a number of work directories under both.
>
> It seems to me there are these possibilities:
>
>
> 1) There are at least two different (and disagreeing) methods to compute the architecture "tuple," and different pieces of the system are choosing different methods. These different methods usually agree, but sometimes they don't. Thus, when they *do* agree, it's "luck."
>
>
> 2) These strings *should* agree, but something is missing from our machine definition that causes them to disagree (we weren't using our own machine definition until recently). In that case, the machine definition code should change such that it's not *possible* for these strings to disagree. Also, I'd like to know what we missed, so we can fix it.
>
>
> 3) These strings, though similar, actually *mean* different things and are *both* correct. The only problem is that the build process for the tool chain chooses the wrong one when defining the default sysroot path.
>
>
> In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution.
>
> _______________________________________________
> yocto mailing list
> yocto@...
> https://lists.yoctoproject.org/listinfo/yocto
>


Re: Inconsistency in the SDK

Zhang, Jessica
 

Please file a bug at bugzilla.yoctoproject.org

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Patrick Turley
Sent: Wednesday, January 23, 2013 8:06 AM
To: yocto@...
Subject: [yocto] Inconsistency in the SDK

Here's our machine in local.conf:

MACHINE = "dm8148-mpu"

Naturally, then, we see a directly like this under tmp/work:

dm8148_mpu-poky-linux-gnueabi

Also, under tmp/sysroots, we see these two:

dm8148-mpu
dm8148-mpu-tcbootstrap

Finally, when I install the SDK, I see the following under sysroots:

dm8148_mpu-poky-linux-gnueabi
x86_64-pokysdk-linux

However, if I ask the cross-compiler the path to its default sysroot, I see this:

$ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux
$ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
$ ./arm-poky-linux-gnueabi-gcc -print-sysroot
/opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

There is no such directory. That is, the default sysroot for the SDK doesn't exist.

Now, if I go back and look in tmp/work, I realize that I see *both* of these:

dm8148_mpu-poky-linux-gnueabi
armv7a-vfp-neon-poky-linux-gnueabi

There are a number of work directories under both.

It seems to me there are these possibilities:


1) There are at least two different (and disagreeing) methods to compute the architecture "tuple," and different pieces of the system are choosing different methods. These different methods usually agree, but sometimes they don't. Thus, when they *do* agree, it's "luck."


2) These strings *should* agree, but something is missing from our machine definition that causes them to disagree (we weren't using our own machine definition until recently). In that case, the machine definition code should change such that it's not *possible* for these strings to disagree. Also, I'd like to know what we missed, so we can fix it.


3) These strings, though similar, actually *mean* different things and are *both* correct. The only problem is that the build process for the tool chain chooses the wrong one when defining the default sysroot path.


In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution.

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


SRC_URI checksums

Darren Hart <dvhart@...>
 

What is the practice for SRC_URI checksums? I see many recipes with both
md5sum and sha256sum. Is there a need to have both? Is one preferred
over the other?

Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


Inconsistency in the SDK

Patrick Turley <PatrickTurley@...>
 

Here's our machine in local.conf:

MACHINE = "dm8148-mpu"

Naturally, then, we see a directly like this under tmp/work:

dm8148_mpu-poky-linux-gnueabi

Also, under tmp/sysroots, we see these two:

dm8148-mpu
dm8148-mpu-tcbootstrap

Finally, when I install the SDK, I see the following under sysroots:

dm8148_mpu-poky-linux-gnueabi
x86_64-pokysdk-linux

However, if I ask the cross-compiler the path to its default sysroot, I see this:

$ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux
$ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
$ ./arm-poky-linux-gnueabi-gcc -print-sysroot
/opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

There is no such directory. That is, the default sysroot for the SDK doesn't exist.

Now, if I go back and look in tmp/work, I realize that I see *both* of these:

dm8148_mpu-poky-linux-gnueabi
armv7a-vfp-neon-poky-linux-gnueabi

There are a number of work directories under both.

It seems to me there are these possibilities:


1) There are at least two different (and disagreeing) methods to compute the architecture "tuple," and different pieces of the system are choosing different methods. These different methods usually agree, but sometimes they don't. Thus, when they *do* agree, it's "luck."


2) These strings *should* agree, but something is missing from our machine definition that causes them to disagree (we weren't using our own machine definition until recently). In that case, the machine definition code should change such that it's not *possible* for these strings to disagree. Also, I'd like to know what we missed, so we can fix it.


3) These strings, though similar, actually *mean* different things and are *both* correct. The only problem is that the build process for the tool chain chooses the wrong one when defining the default sysroot path.


In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution.


[OT] the beauty of yocto/OE doing all your license tracking for you

Robert P. J. Day
 

just noticed this online -- "How Much Disruption Will Scanning For
OSS Cause Me?:

http://www.openlogic.com/blog/bid/249485/How-Much-Disruption-Will-Scanning-For-OSS-Cause-Me?utm_source=twitter&utm_medium=social&utm_content=86ee217f-b5bc-4a65-b643-743878c36b25

"Scanning and auditing your code for open source software (OSS) is a
great first step towards compliance. However, some organizations may
be reluctant to perform scans because of concerns about how disruptive
the process can be to their development effort."

just thought some folks might find that interesting.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 23, 2013, at 7:48 AM, Bruce Ashfield <bruce.ashfield@...>
wrote:
On 13-01-23 12:34 AM, Patrick Turley wrote:

On Jan 22, 2013, at 11:17 PM, Bruce Ashfield <bruce.ashfield@...> wrote:

On 13-01-23 12:14 AM, Patrick Turley wrote:
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield@...> wrote:
On 13-01-22 9:26 PM, Patrick Turley wrote:
Argh. I'll have to just run the commands myself and stop spamming the
list with ideas :) It's just a matter of making lkc accept the defaults
(i.e. you could also use allyesconfig, or allnoconfig) or even better
not trigger that config check at all.
You're very kind to have spent so much time on my problem already. I look forward to hearing back.


Re: Build external module against Yocto kernel

Bruce Ashfield <bruce.ashfield@...>
 

On 13-01-23 12:34 AM, Patrick Turley wrote:

On Jan 22, 2013, at 11:17 PM, Bruce Ashfield <bruce.ashfield@...> wrote:

On 13-01-23 12:14 AM, Patrick Turley wrote:
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield@...> wrote:
On 13-01-22 9:26 PM, Patrick Turley wrote:
If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?
No -- "make oldconfig" caused the very same questions (see below).
Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)

Nope - still doesn't work.
Argh. I'll have to just run the commands myself and stop spamming the
list with ideas :) It's just a matter of making lkc accept the defaults
(i.e. you could also use allyesconfig, or allnoconfig) or even better
not trigger that config check at all.

Cheers,

Bruce


--------------------

$ sudo make silentoldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:


[PATCH v4] [local patch for org.eclipse.rse.services]Fix race conditions for reading output from local processes

Ioana Grigoropol <ioanax.grigoropol@...>
 

When running a command using RSE Api, using a Local connection from a linux host a new LocalHostShell is created.
When this is created, a new LocalHostThread is launched, along side with two LocalShellOutputReaders (output and error). The constructors for the OutputReaders will receive a reference to the reader created by the LocalHostThread.

When calling runCommandRemote, the newly creared IHostShell is returned, making it possible to create an adapter(IHostShellProcessAdapter) that will then be used to read all available output from the readers.
When the LocalHostThread finishes running its run() method, it will perform a cleanup causing both readers (output and error) to be closed. If at this point, there are any readers, or handlers to the readers that are still trying to read data (using internalReadLine or read on handlers), obviously, an error will be thrown saying that the the pipe to the stream is closed ("Ensure open stream"/ "Pipe closed" errors).
After inspecting the internalReadLine, it seems that it expects a null reference of the reader in order to consider that the reading is done. In order to ensure that this will happen once the LocalHostThread closes the stream(s), we will make sure that the reference to the readers is set to null, and that LocalShellOutputReaders use the same reference. For this to happen, a reference of the thread must be kept in the reader, in order to retrieve the correct reference of the underlying reader.
Since there can still be race conditions in this solution, all operations that involve the reference to now the only reader, must be performed under mutual exclusion using a shared lock between the LocalShellOutputReader and LocalHostThread.

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...>
---
.../dstore/shells/DStoreShellOutputReader.java | 14 +++++-
.../services/local/shells/LocalHostShell.java | 6 +--
.../local/shells/LocalShellOutputReader.java | 46 ++++++++++++++------
.../services/local/shells/LocalShellThread.java | 18 ++++++++
.../.settings/.api_filters | 38 ++++++++++++----
.../shells/TerminalServiceShellOutputReader.java | 10 +++++
.../services/shells/IHostShellOutputReader.java | 11 +++++
7 files changed, 118 insertions(+), 25 deletions(-)

diff --git a/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java b/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
index 84c9bb9..281e240 100644
--- a/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
+++ b/rse/plugins/org.eclipse.rse.services.dstore/src/org/eclipse/rse/internal/services/dstore/shells/DStoreShellOutputReader.java
@@ -17,6 +17,9 @@

package org.eclipse.rse.internal.services.dstore.shells;

+import java.io.BufferedReader;
+import java.util.concurrent.locks.Lock;
+
import org.eclipse.dstore.core.model.DataElement;
import org.eclipse.dstore.extra.DomainEvent;
import org.eclipse.dstore.extra.IDomainListener;
@@ -167,7 +170,16 @@ public class DStoreShellOutputReader extends AbstractHostShellOutputReader imple
super.finish();
notifyResponse();
}
-
+
+ public BufferedReader getReader() {
+ // TODO Auto-generated method stub
+ return null;
+ }
+
+ public Lock getReaderLock() {
+ return null;
+ }
+
/*
private void handleInput()
{
diff --git a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
index 250a904..3179bab 100644
--- a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
+++ b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalHostShell.java
@@ -36,9 +36,9 @@ public class LocalHostShell extends AbstractHostShell implements IHostShell

public LocalHostShell(String initialWorkingDirectory, String invocation, String encoding, String[] environment)
{
- _shellThread = new LocalShellThread(initialWorkingDirectory, invocation, encoding, environment);
- _stdoutHandler = new LocalShellOutputReader(this, _shellThread.getOutputStream(), false);
- _stderrHandler = new LocalShellOutputReader(this, _shellThread.getErrorStream(),true);
+ _shellThread = new LocalShellThread(initialWorkingDirectory, invocation, encoding, environment);
+ _stdoutHandler = new LocalShellOutputReader(this, _shellThread.getOutputStream(), _shellThread, false);
+ _stderrHandler = new LocalShellOutputReader(this, _shellThread.getErrorStream(), _shellThread, true);
}

protected void run(IProgressMonitor monitor)
diff --git a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellOutputReader.java b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellOutputReader.java
index ab8ff5c..021095e 100644
--- a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellOutputReader.java
+++ b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellOutputReader.java
@@ -19,6 +19,7 @@ package org.eclipse.rse.internal.services.local.shells;

import java.io.BufferedReader;
import java.io.IOException;
+import java.util.concurrent.locks.Lock;

import org.eclipse.rse.internal.services.local.Activator;
import org.eclipse.rse.services.shells.AbstractHostShellOutputReader;
@@ -33,14 +34,16 @@ import org.eclipse.rse.services.shells.SimpleHostOutput;
*/
public class LocalShellOutputReader extends AbstractHostShellOutputReader implements IHostShellOutputReader
{
- protected BufferedReader _reader;
+// protected volatile BufferedReader _reader;
+ private LocalShellThread _shellThread;
private String fPromptChars = ">$%#]"; //Characters we accept as the end of a prompt //$NON-NLS-1$;

-
- public LocalShellOutputReader(IHostShell hostShell, BufferedReader reader, boolean isErrorReader)
+
+ public LocalShellOutputReader(IHostShell hostShell, BufferedReader reader, LocalShellThread shellThread, boolean isErrorReader)
{
super(hostShell, isErrorReader);
- _reader = reader;
+// _reader = reader;
+ _shellThread = shellThread;
}
/*
protected Object internalReadLine()
@@ -137,9 +140,11 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
}
*/
protected IHostOutput internalReadLine() {
- if (_reader == null) {
+ getLock().lock();
+ if (getReader() == null) {
//Our workaround sets the stderr reader to null, so we never give any stderr output.
//TODO Check if ssh supports some method of having separate stdout and stderr streams
+ getLock().unlock();
return null;
}
StringBuffer theLine = new StringBuffer();
@@ -149,12 +154,14 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
boolean done = false;
while (!done && !isFinished()) {
try {
- ch = _reader.read();
+ ch = getReader().read();
switch (ch) {
case -1:
case 65535:
- if (theLine.length() == 0) // End of Reader
+ if (theLine.length() == 0) {// End of Reader
+ getLock().unlock();
return null;
+ }
done = true;
break;
case '\b': //backspace
@@ -185,13 +192,13 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
theLine.append(tch); // Any other character
} else if (ch == 27) {
// Escape: ignore next char too
- int nch = _reader.read();
+ int nch = getReader().read();
if (theDebugLine!=null) theDebugLine.append((char)nch);
if (nch == 91) {
//vt100 escape sequence: read until end-of-command (skip digits and semicolon)
//e.g. \x1b;13;m --> ignore the entire command, including the trailing m
do {
- nch = _reader.read();
+ nch = getReader().read();
if (theDebugLine!=null) theDebugLine.append((char)nch);
} while (Character.isDigit((char)nch) || nch == ';');
}
@@ -202,9 +209,9 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
// there are more characters
// in the Buffer...If not, then we assume it is waiting for
// input.
- if (!done && !_reader.ready()) {
- // wait to make sure -- max. 500 msec to wait for new chars
- // if we are not at a CRLF seems to be appropriate for the
+ if (!done && !getReader().ready()) {
+ // wait to make sure -- max. 500 msec to wait for new chars
+ // if we are not at a CRLF seems to be appropriate for the
// Pipes and Threads in ssh.
long waitIncrement = 500;
// Check if we think we are at a prompt
@@ -219,7 +226,7 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
Thread.sleep(waitIncrement);
} catch (InterruptedException e) {
}
- if (!_reader.ready()) {
+ if (!getReader().ready()) {
done = true;
}
}
@@ -228,6 +235,7 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
//our reader thread completely... the exception could just be
//temporary, and we should keep running!
Activator.getDefault().logException(e);
+ getLock().unlock();
return null;
}
}
@@ -235,8 +243,20 @@ public class LocalShellOutputReader extends AbstractHostShellOutputReader implem
String debugLine = theDebugLine.toString();
debugLine.compareTo(""); //$NON-NLS-1$
}
+ getLock().unlock();
return new SimpleHostOutput(theLine.toString());
}
+ private Lock getLock() {
+ return _shellThread.getLock();
+ }
+ public BufferedReader getReader() {
+ if (isErrorReader())
+ return _shellThread.getErrorStream();
+ return _shellThread.getOutputStream();
+ }
+ public Lock getReaderLock() {
+ return _shellThread.getLock();
+ }


}
diff --git a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellThread.java b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellThread.java
index 0a33ad4..18f1373 100644
--- a/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellThread.java
+++ b/rse/plugins/org.eclipse.rse.services.local/src/org/eclipse/rse/internal/services/local/shells/LocalShellThread.java
@@ -29,6 +29,8 @@ import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.URL;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;

import org.eclipse.core.runtime.FileLocator;

@@ -62,6 +64,7 @@ public class LocalShellThread extends Thread
private BufferedReader _stdInput;
private BufferedReader _stdError;

+ private Lock _lock;
/**
* constructor for local command shell monitor
*
@@ -260,6 +263,7 @@ public class LocalShellThread extends Thread

_stdError = new BufferedReader(new InputStreamReader(_theProcess.getErrorStream()));

+ _lock = new ReentrantLock();
}
catch (IOException e)
{
@@ -438,9 +442,14 @@ public class LocalShellThread extends Thread
_isDone = true;
try
{
+ _lock.lock();
_stdInput.close();
_stdError.close();

+ _stdInput = null;
+ _stdError = null;
+
+ _lock.unlock();
if (_theProcess != null)
{

@@ -511,4 +520,13 @@ public class LocalShellThread extends Thread
}


+ public Lock getLock() {
+ return _lock;
+ }
+
+
+ public void setLock(Lock _lock) {
+ this._lock = _lock;
+ }
+
}
diff --git a/rse/plugins/org.eclipse.rse.services/.settings/.api_filters b/rse/plugins/org.eclipse.rse.services/.settings/.api_filters
index 19273c2..da9417a 100644
--- a/rse/plugins/org.eclipse.rse.services/.settings/.api_filters
+++ b/rse/plugins/org.eclipse.rse.services/.settings/.api_filters
@@ -1,5 +1,13 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<component id="org.eclipse.rse.services" version="2">
+ <resource path="META-INF/MANIFEST.MF">
+ <filter id="923795461">
+ <message_arguments>
+ <message_argument value="3.2.200"/>
+ <message_argument value="3.2.200"/>
+ </message_arguments>
+ </filter>
+ </resource>
<resource path="META-INF/MANIFEST.MF" type="org.eclipse.rse.internal.services.terminals.AbstractTerminalService">
<filter id="305324134">
<message_arguments>
@@ -32,13 +40,13 @@
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.BaseShellDecorator"/>
- <message_argument value="org.eclipse.rse.services_3.1.1"/>
+ <message_argument value="org.eclipse.rse.services_3.1.0"/>
</message_arguments>
</filter>
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.BaseShellDecorator"/>
- <message_argument value="org.eclipse.rse.services_3.1.0"/>
+ <message_argument value="org.eclipse.rse.services_3.1.1"/>
</message_arguments>
</filter>
</resource>
@@ -46,13 +54,13 @@
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.IBaseShell"/>
- <message_argument value="org.eclipse.rse.services_3.1.1"/>
+ <message_argument value="org.eclipse.rse.services_3.1.0"/>
</message_arguments>
</filter>
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.IBaseShell"/>
- <message_argument value="org.eclipse.rse.services_3.1.0"/>
+ <message_argument value="org.eclipse.rse.services_3.1.1"/>
</message_arguments>
</filter>
</resource>
@@ -88,13 +96,13 @@
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.TerminalShellDecorator"/>
- <message_argument value="org.eclipse.rse.services_3.1.1"/>
+ <message_argument value="org.eclipse.rse.services_3.1.0"/>
</message_arguments>
</filter>
<filter id="305324134">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.TerminalShellDecorator"/>
- <message_argument value="org.eclipse.rse.services_3.1.0"/>
+ <message_argument value="org.eclipse.rse.services_3.1.1"/>
</message_arguments>
</filter>
</resource>
@@ -109,13 +117,27 @@
<filter id="305365105">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.ProcessBaseShell"/>
- <message_argument value="org.eclipse.rse.services_3.1.1"/>
+ <message_argument value="org.eclipse.rse.services_3.1.0"/>
</message_arguments>
</filter>
<filter id="305365105">
<message_arguments>
<message_argument value="org.eclipse.rse.internal.services.terminals.ProcessBaseShell"/>
- <message_argument value="org.eclipse.rse.services_3.1.0"/>
+ <message_argument value="org.eclipse.rse.services_3.1.1"/>
+ </message_arguments>
+ </filter>
+ </resource>
+ <resource path="src/org/eclipse/rse/services/shells/IHostShellOutputReader.java" type="org.eclipse.rse.services.shells.IHostShellOutputReader">
+ <filter id="403804204">
+ <message_arguments>
+ <message_argument value="org.eclipse.rse.services.shells.IHostShellOutputReader"/>
+ <message_argument value="getReader()"/>
+ </message_arguments>
+ </filter>
+ <filter id="403804204">
+ <message_arguments>
+ <message_argument value="org.eclipse.rse.services.shells.IHostShellOutputReader"/>
+ <message_argument value="getReaderLock()"/>
</message_arguments>
</filter>
</resource>
diff --git a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceShellOutputReader.java b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceShellOutputReader.java
index 16364e1..11b07eb 100644
--- a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceShellOutputReader.java
+++ b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/internal/services/shells/TerminalServiceShellOutputReader.java
@@ -23,6 +23,8 @@ package org.eclipse.rse.internal.services.shells;

import java.io.BufferedReader;
import java.io.IOException;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;

import org.eclipse.rse.internal.services.Activator;
import org.eclipse.rse.services.shells.AbstractHostShellOutputReader;
@@ -174,4 +176,12 @@ public class TerminalServiceShellOutputReader extends
fReaderThread.interrupt();
}
}
+
+ public BufferedReader getReader() {
+ return fReader;
+ }
+
+ public Lock getReaderLock() {
+ return new ReentrantLock();
+ }
}
diff --git a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/IHostShellOutputReader.java b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/IHostShellOutputReader.java
index 103c31f..5f8bf78 100644
--- a/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/IHostShellOutputReader.java
+++ b/rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/shells/IHostShellOutputReader.java
@@ -16,6 +16,9 @@

package org.eclipse.rse.services.shells;

+import java.io.BufferedReader;
+import java.util.concurrent.locks.Lock;
+
public interface IHostShellOutputReader extends IHostShellOutputNotifier
{
public IHostOutput readLine();
@@ -23,4 +26,12 @@ public interface IHostShellOutputReader extends IHostShellOutputNotifier
public void addOutputListener(IHostShellOutputListener listener);
public boolean isErrorReader();
public void finish();
+ /**
+ * @since 3.2
+ */
+ public BufferedReader getReader();
+ /**
+ * @since 3.2
+ */
+ public Lock getReaderLock();
}
\ No newline at end of file
--
1.7.9.5


Re: [meta-ivi][meta-fsl-arm] Kernel AF_BUS dependency?

Behrens, Holger <Holger.Behrens@...>
 

Hi Adrian,

Hi Holger, Florin

I'm building excalibur-image from meta-ivi and I can't login to the system
See: http://pastebin.com/fRUJsaae

Two issues:

systemd-random-seed-load service, here probably I'm missing in my kernel
config to enable
random number support.

the second is about D-Bus

"Failed to listen on D-Bus System Message Bus Socket"

My question

Do I need AF BUS kernel patch ?

0001-net-bus-add-the-AF_BUS-socket-address-family.patch

The kernel that I'm using is kernel version 3.0.35.
You may look into the (systemd) journal, it may point to the problem at hand, like a missing file, access rights, or kernel configuration required.

For D-Bus to work you won't need the AF_BUS patch series, it should work without. It is not GENIVI compliant, but it must work without.

Regards,
Holger

Best regards.

--
Saludos
Adrian Alonso
http://aalonso.wordpress.com


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 22, 2013, at 11:17 PM, Bruce Ashfield <bruce.ashfield@...> wrote:

On 13-01-23 12:14 AM, Patrick Turley wrote:
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield@...> wrote:
On 13-01-22 9:26 PM, Patrick Turley wrote:
If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?
No -- "make oldconfig" caused the very same questions (see below).
Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)

Nope - still doesn't work.

--------------------

$ sudo make silentoldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:


Re: Build external module against Yocto kernel

Bruce Ashfield <bruce.ashfield@...>
 

On 13-01-23 12:14 AM, Patrick Turley wrote:
On Jan 22, 2013, at 10:43 PM, Bruce Ashfield<bruce.ashfield@...> wrote:
On 13-01-22 9:26 PM, Patrick Turley wrote:
If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?
No -- "make oldconfig" caused the very same questions (see below).
Aha. of course (now that I think about it), the build was simply triggering
old config automatically.

silentoldconfig is what I really should have typed :)

Bruce


-------------------

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls
arch drivers Kbuild MAINTAINERS README System.map-2.6.37
block firmware Kconfig Makefile REPORTING-BUGS tools
COPYING fs kernel mm samples uImage
CREDITS include kernel-abiversion Module.symvers scripts usr
crypto init kernel-image-name net security virt
Documentation ipc lib patches sound

$ sudo make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 22, 2013, at 10:43 PM, Bruce Ashfield <bruce.ashfield@...> wrote:
On 13-01-22 9:26 PM, Patrick Turley wrote:
If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?
No -- "make oldconfig" caused the very same questions (see below).

-------------------

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls
arch drivers Kbuild MAINTAINERS README System.map-2.6.37
block firmware Kconfig Makefile REPORTING-BUGS tools
COPYING fs kernel mm samples uImage
CREDITS include kernel-abiversion Module.symvers scripts usr
crypto init kernel-image-name net security virt
Documentation ipc lib patches sound

$ sudo make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:


Re: Build external module against Yocto kernel

Bruce Ashfield <bruce.ashfield@...>
 

On 13-01-22 9:26 PM, Patrick Turley wrote:
On Jan 22, 2013, at 2:34 PM, Bruce Ashfield<bruce.ashfield@...> wrote:
On 13-01-22 03:28 PM, Patrick Turley wrote:
One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
Interesting. I haven't seen this myself, so just a couple of quick
questions:

- without the .config, did you still get a working set of hostprogs, and
only had to suffer the warnings ?

- If the answer is yes, then the .config really doesn't matter for this
and the approach of grabbing a .config should work fine or even
having a dummy defconfig available with enough to keep the build
happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.
Below, please find a transcript of the commands I executed.

You'll see that I installed the SDK, tried to "make scripts," and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow.

There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory:

/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are.

If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)
This will be fine, the defaults will work. The kernel build infrastructure
is picking up what it thinks is a change source -> to config and trying
to reconcile the differences.

If you throw in a 'make oldconfig' before you do the 'make scripts', does
that quiet things down a bit ?

Cheers,

Bruce

--------------------

$ pwd
/home/pturley/yocto-mpu-build/tmp/deploy/sdk

$ ls
poky-eglibc-x86_64-arm-toolchain-1.3.sh

$ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls -a
. firmware lib scripts
.. fs MAINTAINERS security
arch include Makefile sound
block init mm System.map-2.6.37
.config ipc Module.symvers tools
COPYING Kbuild net uImage
CREDITS Kconfig patches usr
crypto kernel README virt
Documentation kernel-abiversion REPORTING-BUGS
drivers kernel-image-name samples

$ sudo make scripts
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:
Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n
System V IPC (SYSVIPC) [Y/n/?] y
POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y
BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y
Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y
Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y
Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y
Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y
Auditing support (AUDIT) [N/y/?] n
Kernel .config support (IKCONFIG) [Y/n/m/?] y
Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y
Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17] 17
enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n
Kernel->user space relay support (formerly relayfs) (RELAY) [N/y/?] n
Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y
Initramfs source file(s) (INITRAMFS_SOURCE) []
Optimize for size (CC_OPTIMIZE_FOR_SIZE) [Y/n/?] y
Disable heap randomization (COMPAT_BRK) [Y/n/?] y
Choose SLAB allocator
1. SLAB (SLAB)
2. SLUB (Unqueued Allocator) (SLUB)
choice[1-2?]: 2
Profiling support (PROFILING) [Y/n/?] y
OProfile system profiling (OPROFILE) [M/n/y/?] m
OProfile multiplexing support (EXPERIMENTAL) (OPROFILE_EVENT_MULTIPLEX) [N/y/?] (NEW)


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 22, 2013, at 2:34 PM, Bruce Ashfield <bruce.ashfield@...> wrote:
On 13-01-22 03:28 PM, Patrick Turley wrote:
One problem I ran into … When I tried to execute "make scripts," I got a whole bunch of config questions that I *think* should have been answered with a .config file or something. Should I have copied out the .config file from the kernel work directory into the SDK installation before I ran that? Is that the "best" way to get around all the questions?
Interesting. I haven't seen this myself, so just a couple of quick
questions:

- without the .config, did you still get a working set of hostprogs, and
only had to suffer the warnings ?

- If the answer is yes, then the .config really doesn't matter for this
and the approach of grabbing a .config should work fine or even
having a dummy defconfig available with enough to keep the build
happy.

Definitely sounds like something we can address and it's worth putting into
bugzilla so it doesn't get lost.
Below, please find a transcript of the commands I executed.

You'll see that I installed the SDK, tried to "make scripts," and then got attacked with a storm of config questions. I cut off the transcript at the second question, but there are dozens that follow.

There *is* a .config file in the SDK directory, and it is identical to the one in our kernel build directory:

/home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git

Unfortunately, I'm still something of a n00b when it comes to building the kernel. I suspect *most* of these questions are irrelevant to hostprogs, but I can't say that *all* of them are.

If I just hold down the "Enter" key, I believe all the defaults are taken, and I eventually *do* get hostprogs that execute, but I don't know if they're appropriate to my kernel. (Again, I'm a n00b, so perhaps there's no effect at all.)

--------------------

$ pwd
/home/pturley/yocto-mpu-build/tmp/deploy/sdk

$ ls
poky-eglibc-x86_64-arm-toolchain-1.3.sh

$ sudo ./poky-eglibc-x86_64-arm-toolchain-1.3.sh
Enter target directory for SDK (default: /opt/poky/1.3):
You are about to install the SDK to "/opt/poky/1.3". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

$ cd /opt/poky/1.3/sysroots/dm8148_mpu-poky-linux-gnueabi/usr/src/kernel

$ ls -a
. firmware lib scripts
.. fs MAINTAINERS security
arch include Makefile sound
block init mm System.map-2.6.37
.config ipc Module.symvers tools
COPYING Kbuild net uImage
CREDITS Kconfig patches usr
crypto kernel README virt
Documentation kernel-abiversion REPORTING-BUGS
drivers kernel-image-name samples

$ sudo make scripts
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] y
Cross-compiler tool prefix (CROSS_COMPILE) []
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Kernel compression mode
1. Gzip (KERNEL_GZIP)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA)
4. LZO (KERNEL_LZO)
choice[1-4?]:
Support for paging of anonymous memory (swap) (SWAP) [N/y/?] n
System V IPC (SYSVIPC) [Y/n/?] y
POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
BSD Process Accounting (BSD_PROCESS_ACCT) [Y/n/?] y
BSD Process Accounting version 3 file format (BSD_PROCESS_ACCT_V3) [Y/n/?] y
Export task/process statistics through netlink (EXPERIMENTAL) (TASKSTATS) [Y/n/?] y
Enable per-task delay accounting (EXPERIMENTAL) (TASK_DELAY_ACCT) [Y/n/?] y
Enable extended accounting over taskstats (EXPERIMENTAL) (TASK_XACCT) [Y/n/?] y
Enable per-task storage I/O accounting (EXPERIMENTAL) (TASK_IO_ACCOUNTING) [Y/n/?] y
Auditing support (AUDIT) [N/y/?] n
Kernel .config support (IKCONFIG) [Y/n/m/?] y
Enable access to .config through /proc/config.gz (IKCONFIG_PROC) [Y/n/?] y
Kernel log buffer size (16 => 64KB, 17 => 128KB) (LOG_BUF_SHIFT) [17] 17
enable deprecated sysfs features to support old userspace tools (SYSFS_DEPRECATED) [N/y/?] n
Kernel->user space relay support (formerly relayfs) (RELAY) [N/y/?] n
Initial RAM filesystem and RAM disk (initramfs/initrd) support (BLK_DEV_INITRD) [Y/n/?] y
Initramfs source file(s) (INITRAMFS_SOURCE) []
Optimize for size (CC_OPTIMIZE_FOR_SIZE) [Y/n/?] y
Disable heap randomization (COMPAT_BRK) [Y/n/?] y
Choose SLAB allocator
1. SLAB (SLAB)
2. SLUB (Unqueued Allocator) (SLUB)
choice[1-2?]: 2
Profiling support (PROFILING) [Y/n/?] y
OProfile system profiling (OPROFILE) [M/n/y/?] m
OProfile multiplexing support (EXPERIMENTAL) (OPROFILE_EVENT_MULTIPLEX) [N/y/?] (NEW)