Date   

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)


M2/M3.rc1 availability

Flanagan, Elizabeth <elizabeth.flanagan@...>
 

The weekly build is available at:

http://autobuilder.yoctoproject.org/pub/nightly/20130122-2

This build is built from master HEAD.

Please begin testing against this rc. Please note that tag and branch
names for this milestone will be named as if it was M3. I will be
tagging tonight and branching in the morning once given the all clear
by RP.


-b


--
Elizabeth Flanagan
Yocto Project
Build and Release


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

Adrian Alonso <aalonso00@...>
 

Hi Holger, Florin

I'm building excalibur-image from meta-ivi and I can't login to the system

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.

Best regards.

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


Yocto Project Developer at Embedded Linux Conference US

Jeff Osier-Mixon <jefro@...>
 

Hi all & happy new year

The conference season starts early this year with several open source conferences worldwide, including FOSDEM in Brussels, linux.conf.au in Canberra, several regional Linux conferences including SCaLE in southern California, and of course the Embedded Linux Conference (ELC), February 20-22 in San Francisco, CA. 

This year the Yocto Project is focusing once again on ELC and will again be hosting a Developer Day (http://events.linuxfoundation.org/events/embedded-linux-conference/yocto-project-developer-day) on Tuesday, February 19.

Developer Day features talks and demos from Yocto Project engineers as well as an opportunity to connect one-on-one with those engineers to discuss issues you may be having with your own development process. 

The Yocto Project is also pleased to participate in ELC. We are preparing a booth and a BoF, and there are several talks on the schedule which mention the Yocto Project. If you are coming to the conference, please stop by and say hello, and consider joining us for Developer Day.

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


Re: High-level roadmap

Philip Balister
 

On 01/22/2013 01:59 PM, Paul Eggleton wrote:
Hi all,

I was recently asked for a high-level roadmap for future releases, and I
couldn't find anything to point to on our website. We have this wiki page, but
it's somewhat out of date:

https://wiki.yoctoproject.org/wiki/Yocto_Project_Roadmap

Do we have anything else at the moment? If not could something be written up
and kept up-to-date?
I think that page updated with the major features added in the releases
to date, combined with features for the next release would be a good
start showing what the Project has done, so people can think about other
ways to make Embedded Development easier.

Philip


Re: [PATCH] scripts/build.sh: Fixed local build to use the correct repository path

Zhang, Jessica
 

Merged to eclipse-poky master.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Timo Mueller
Sent: Tuesday, January 22, 2013 4:03 AM
To: yocto@...
Cc: Timo Mueller
Subject: [yocto] [PATCH] scripts/build.sh: Fixed local build to use the correct repository path

From: Timo Mueller <timo.mueller@...>


Signed-off-by: Timo Mueller <timo.mueller@...>
---
scripts/build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/build.sh b/scripts/build.sh index 54081d5..8d8b4c3 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -115,7 +115,7 @@ mkdir ${BUILD_DIR} || fail $? "Create temporary build directory ${BUILD_DIR}"
GIT_URL=git://git.pokylinux.org/eclipse-poky.git
if [ $USE_LOCAL_GIT_REPO -eq 1 ]; then
SCRIPT_DIR=`dirname $0`
- GIT_DIR=`readlink -f ${SCRIPTDIR}\..`
+ GIT_DIR=`readlink -f ${SCRIPT_DIR}\..`
GIT_URL="file://${GIT_DIR}"
fi

--
1.7.11.7

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


Re: FW: YP Linux Kernel Development Manual

Christian Ege <chege@...>
 

Am Dienstag, den 22.01.2013, 11:14 +0100 schrieb Darren Hart <darren.hart@...>:
On 01/22/2013 12:59 AM, Christian Ege wrote:
Hi,
I am not sure if this is the problem you are struggling with.
I am wondering why class module.bbclass behaves completely different
than kernel.bbclacc

hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add
"MACHINE_EXTRA_
RDEPENDS += "kernel-module-hello" in the conf/local.conf
after build and boot, there's no "hello.ko" found in the binary
image
also there's no hello.ko in the "tmp/work/..." folder
If you hello-mod_0.1.bb inherits module class there is no mechanism
to create the kernel-module package. This only applies to the
kernel.bbclass

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass

Have a look at kernel.bbclass instead shows some pathon code which
handles the module package creation:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301

I've fixed this in my layer by stealing the code from kernel.bbclass
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc

With this you can also use the following extends with your module:
module_autoload_aotom = "aotom"
and
module_conf_stmfb = "options stmfb
display0=1280x720-32@50:8m:pal:yuv:yuv"
Christian, this is a really good point I hadn't considered. Would you
care to take a stab at adding this to module.bbclass and sending the
patch to the oe-core list for review? CC'ing myself?
I'll try to write a patch. Maybe tomorrow or by end of the week. I'll send it to oe-core and
to you in CC.

regrads,

Christian


Thanks,


Re: Build external module against Yocto kernel

Bruce Ashfield <bruce.ashfield@...>
 

On 13-01-22 03:28 PM, Patrick Turley wrote:
On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@...> wrote:
On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)
You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between "target image" recipes and "SDK image" recipes. I believe I get that now.

We've created a target image recipe, and an SDK image recipe that "require's" the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.

As I described in an earlier post, I am currently reaching into the "tmp" directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the build artifacts, and it's awkward to distribute.

With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute.

With regard to:

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

This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems.

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.

Bruce

Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.
It's very *nearly* working for me now. See my question above.


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 16, 2013, at 11:11 AM, Darren Hart <dvhart@...> wrote:
On 01/15/2013 10:38 AM, Bruce Ashfield wrote:
I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the LDFLAGS
tweaks mentioned in the other thread). The sources should be part
of the sysroot, and hence available when that is packaged for use
outside of bitbake/yocto.

If you aren't seeing kernel-dev in the SDK image, it might be that
TOOLCHAIN_TARGET_TASK doesn't have kernel-dev by default, or something
else is different in the SDK that is being generated in your testing.

I'm only speculating about what might be missing, since I'm not 100%
familiar with the SDK, but perhaps Jessica or others can chime in if
I've led you astray :)
You have *not* led me astray. A fundamental problem was that I didn't comprehend the distinction/correspondence between "target image" recipes and "SDK image" recipes. I believe I get that now.

We've created a target image recipe, and an SDK image recipe that "require's" the former (this is conventional, I believe). The SDK image recipe adds all the development packages and, yes, it includes kernel-dev. So, when I install my SDK now, I certainly *do* get all the kernel header files. As you know, I do *not* get the hostprogs.

As I described in an earlier post, I am currently reaching into the "tmp" directory, pulling out the kernel work directory, and making it directly available to my external build process. This solves my problem because the work directory contains all the header files I need *and* the hostprogs. Of course, it's "bad" because it's not an intended way to use the build artifacts, and it's awkward to distribute.

With the recent improvement, I can now get the kernel header files packaged in the SDK. That's good because it's an intended mechanism and it's easy to distribute.

With regard to:

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

This seems a reasonable solution to the problem of building modules on the target, given the difficulties of dealing with executables. I'm not building modules on the target (I'm cross-compiling them), but this seems to apply anyway. It adds an extra step to SDK installation, but that's the least of our problems.

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?

Patrick, please keep us posted if this continues to not work for you. I
will open a bug to include a section about this in the kernel
development manual.
It's very *nearly* working for me now. See my question above.


Re: Build external module against Yocto kernel

Patrick Turley <PatrickTurley@...>
 

On Jan 15, 2013, at 1:16 PM, "Zhang, Jessica" <jessica.zhang@...> wrote:

For your LDFLAGS question in another email thread, the yocto SDK is mainly produced for application developer, but seems we are hearing more usage request for it to support kernel module build as well. As Eric pointed, can you just set LDFLAGS="" and we'll add that instruction to developer's manual?
I *can* clear the LDFLAGS variable just before building modules against the kernel. That works.

I understand history makes this difficult, and this is a problem OE/Yocto wasn't originally *intended* to solve. My use case in an outlier, and I don't presume to know what "should" be done. On the other hand, I wouldn't want anyone to feel that putting those instructions in the documentation is a "tidy" solution.


Re: FW: YP Linux Kernel Development Manual

Darren Hart <darren.hart@...>
 

On 01/22/2013 12:59 AM, Christian Ege wrote:
Hi,
I am not sure if this is the problem you are struggling with.
I am wondering why class module.bbclass behaves completely different
than kernel.bbclacc

hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add
"MACHINE_EXTRA_
RDEPENDS += "kernel-module-hello" in the conf/local.conf
after build and boot, there's no "hello.ko" found in the binary
image
also there's no hello.ko in the "tmp/work/..." folder
If you hello-mod_0.1.bb inherits module class there is no mechanism
to create the kernel-module package. This only applies to the
kernel.bbclass

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass

Have a look at kernel.bbclass instead shows some pathon code which
handles the module package creation:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301

I've fixed this in my layer by stealing the code from kernel.bbclass
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc

With this you can also use the following extends with your module:
module_autoload_aotom = "aotom"
and
module_conf_stmfb = "options stmfb
display0=1280x720-32@50:8m:pal:yuv:yuv"
Christian, this is a really good point I hadn't considered. Would you
care to take a stab at adding this to module.bbclass and sending the
patch to the oe-core list for review? CC'ing myself?

Thanks,

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


Re: FW: YP Linux Kernel Development Manual

Darren Hart <darren.hart@...>
 

On 01/21/2013 06:05 PM, Rifenbark, Scott M wrote:
Hi,

I am reposting this to the discussion list and copying Darren Hart.

Scott

From: Eddy Lai GMail [mailto:eddy.lai.tw@...]
Sent: Monday, January 21, 2013 3:36 PM
To: Rifenbark, Scott M
Subject: Re: [yocto] YP Linux Kernel Development Manual

hi

hi, I follow the kernel development manual "2.5. Incorporating Out-of-Tree Modules",
copy the "hello-mod_0.1.bb" and "files" folder into my taget layer "meta-intel/meta-jasperforest/recipe-kernel", then add "MACHINE_EXTRA_ RDEPENDS += "kernel-module-hello" in the conf/local.conf
after build and boot, there's no "hello.ko" found in the binary image
also there's no hello.ko in the "tmp/work/..." folder
From the description below that would be because you have to place the
entire hello-mod directory into
meta-intel/meta-jasperforest/recipes-kernel in order for the stock
layer.conf BBFILES variables to include in the bitbake search path.

If you do indeed have have a space in "MACHINE_EXTRA_ RDEPENDS" as in
your message below, that will also lead to failure.

Thanks,

--
Darren


Eddy

All,



There is a new YP manual under development. It is a development manual for Linux kernels in the YP. Darren Hart is the original author of the manual as you probably know. It is still being worked on but it is in HTML form and now part of the yocto-docs/master branch. It is published at http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html. Feel free to access it and comment.



Thanks,

Scott



Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)





_______________________________________________

yocto mailing list

yocto@...<mailto:yocto@...>

https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel