Date   

[patch] meta-environment

Lu, Lianhao <lianhao.lu@...>
 

Hi all,

The attached patch is to create environment file package used by the ADT installer during ADT installation. This patch should be applied upon my previous pull request of bug#528 fixing (see the following summary of the previous pull request):

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: llu/fix
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/fix

Best Regards,
-Lianhao Lu


Some simple tests about pseudo performance

Xu, Dongxiao <dongxiao.xu@...>
 

Hi,

I did some simple tests for pseudo performance.

I wrote a simple program which is repeatedly calling fopen, fflush, and fclose, which should be sensitive to pseudo/fakeroot since they trap the system calls.

I run the program on native, fakeroot, and pseudo.

int main()
{
FILE *fp;
int i;

for (i = 0; i < 1000000; i++) {
fp = fopen("/tmp/12321.txt", "w");
fflush(fp);
fclose(fp);
}
return 0;
}

Test results are:

Native: 2.729 secs
Fakeroot: 2.752 secs
Pseudo: 51.814 secs

We saw pseudo cost about 20 times of seconds than native and fakeroot.

I did a profile when the program is running. From the following table we saw that a lot of cycles are within sqlite3 operations...

I am wondering whether this point can be optimized? For example, is it workable to cache those database operations in memory and finally flush it into disk when pseudo exits?

It's just a first thought and any suggestion and comment is welcome.

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name app name symbol name
693127 58.2980 no-vmlinux no-vmlinux /no-vmlinux
211108 17.7560 libsqlite3.so.0.8.6 libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so.0.8.6
112269 9.4428 libc-2.10.1.so libc-2.10.1.so /lib/tls/i686/cmov/libc-2.10.1.so
16792 1.4124 [vdso] (tgid:28674 range:0xfd0000-0xfd1000) a.out [vdso] (tgid:28674 range:0xfd0000-0xfd1000)
15256 1.2832 libpthread-2.10.1.so libpthread-2.10.1.so pthread_mutex_lock
13163 1.1071 libpthread-2.10.1.so libpthread-2.10.1.so __pthread_mutex_unlock_usercnt
7386 0.6212 libpseudo.so libpseudo.so pseudo_client_op
6753 0.5680 libpseudo.so libpseudo.so pseudo_debug_real
6680 0.5618 pseudo pseudo pseudo_server_start
6663 0.5604 [vdso] (tgid:28676 range:0x8d6000-0x8d7000) pseudo [vdso] (tgid:28676 range:0x8d6000-0x8d7000)
5049 0.4247 pseudo pseudo pseudo_op
4906 0.4126 [vdso] (tgid:28467 range:0xd32000-0xd33000) a.out [vdso] (tgid:28467 range:0xd32000-0xd33000)
4427 0.3723 [vdso] (tgid:28607 range:0x5c0000-0x5c1000) a.out [vdso] (tgid:28607 range:0x5c0000-0x5c1000)
4391 0.3693 [vdso] (tgid:29027 range:0x6d0000-0x6d1000) a.out [vdso] (tgid:29027 range:0x6d0000-0x6d1000)
4188 0.3522 [vdso] (tgid:29172 range:0x41a000-0x41b000) a.out [vdso] (tgid:29172 range:0x41a000-0x41b000)
3584 0.3014 [vdso] (tgid:2411 range:0x892000-0x893000) a.out [vdso] (tgid:2411 range:0x892000-0x893000)
2985 0.2511 pseudo pseudo pseudo_debug_real
2921 0.2457 postgres postgres /usr/lib/postgresql/8.3/bin/postgres
2905 0.2443 vim.basic vim.basic /usr/bin/vim.basic
2449 0.2060 bash bash /bin/bash
2439 0.2051 libpseudo.so libpseudo.so fopen
2163 0.1819 [vdso] (tgid:28609 range:0x3da000-0x3db000) pseudo [vdso] (tgid:28609 range:0x3da000-0x3db000)
2096 0.1763 [vdso] (tgid:29029 range:0xfef000-0xff0000) pseudo [vdso] (tgid:29029 range:0xfef000-0xff0000)
2086 0.1755 libpseudo.so libpseudo.so pseudo_append_element
1917 0.1612 [vdso] (tgid:28469 range:0xe72000-0xe73000) pseudo [vdso] (tgid:28469 range:0xe72000-0xe73000)
1835 0.1543 libpseudo.so libpseudo.so wrap_fopen
1833 0.1542 libpseudo.so libpseudo.so pseudo_msg_receive
1819 0.1530 libpseudo.so libpseudo.so __lxstat64
1762 0.1482 libpseudo.so libpseudo.so __i686.get_pc_thunk.bx

Thanks,
Dongxiao


Re: PULL] ADT installer script implementation, Liping Ke

Ke, Liping <liping.ke@...>
 

Hi, Richard & Jessica

Actually I am not sure user requirement about the configuration input UI interactive interface

One possible solution is
1) For those can't be changed by users (supported archs, supported os, it is defined by us), I prefer no UI interaction, and hard code in script
2) For those could be changed, but rarely (log file location, image downloading temporary folder, opkg configuration filename), I will still let it in the configuration file,
If configuration file does not exist, I will give a default value. {Question here, do you need I prompt user each of those configurations, and in screen give another chance of changing instead of changing configuration file?)
3) For those need user input (mostly in yocto_installer.conf), if this file does not exist, directly prompt user errors and exit installation? Since without this file, we don't know user want to install what?
So still the question, if already having configuration file, we still need user to input something in screen besides Y or N?

Another question is that since we need to bitbake the installation tarball out. So we will fetch opkg source tarball by bitbake instead of providing a default one in the local folder. Is that right?

Thanks & Regards,
criping

I think it would make most sense for the user to be prompted for unset
values with "enter" selecting a sane set of defaults.

So in summary, I think the right pieces are there in terms of
configuration but the user interaction needs a lot more thought. I
didn't try an actual installation as I don't have a local setup to
allow
it.


Re: PULL] ADT installer script implementation, Liping Ke

Ke, Liping <liping.ke@...>
 

That definitely a bug regarding how to locate .config that we need to
address. As to the different config files, the .config is on purpose
non
user editable that's why we set it as hidden file by default. And the
yocto_installer.conf is the customizable config user should change and
we
have prompt for the user as regard to the configuration values to be
used
and where they're from along the installation process...
Hi, Jessica

For the configuration in .config file, I found it has problem too as a hidden file those days.
It might be missed in some file ops. I was thinking whether I should remove this file
and directly assign values in the common file (such as util script). Normally user will
not change it. If he's capable enough, of course he can change the opkg file name
as well as log file?

As for the rootfs default downloading value, I will remove it to the Yocto_installer.conf

Thanks & Regards,
criping


Re: PULL] ADT installer script implementation, Liping Ke

Ke, Liping <liping.ke@...>
 

The first thing I read was in the patch was:

+# following are for testing in my machine. it will be moved when
+# going into code repository
+export http_proxy=""
+export HTTP_PROXY=""
+export HTTPS_PROXY=""
+export https_proxy=""
+export ftp_proxy=""
+export FTP_PROXY=""

which it evidently wasn't! ;-)

The rest of that file suggests it probably shouldn't be there
actually?
Sorry for this obvious mistake. Need to do a better job before sending
our a
review request next time
Oh, I am sorry that I should not send the [pull] request, instead I should send a review request.
I meant to collect some review comments before finalize the code.

This is for testing. So I did not remove this part. When going into tree,
it will definitely be removed.


I then decided to try it.

cd /
root@rex:/# /rphome/poky/scripts/adt-installer/yocto_installer
/rphome/poky/scripts/adt-installer/yocto_installer: line 207:
.config: No such file or directory [snip lots of similar errors]

So I'd suggest it looks at the location of the main script and then
uses
this to find its config files.

It then found the presetup .config file and took those values as the
defaults. This was not obvious to me, it should perhaps really state
where its getting that config from.

I removed the .config file. That didn't help me so I removed
yocto_installer.conf. This didn't help me much either.
That definitely a bug regarding how to locate .config that we need to
address. As to the different config files, the .config is on purpose
non
user editable that's why we set it as hidden file by default. And the
yocto_installer.conf is the customizable config user should change and
we
have prompt for the user as regard to the configuration values to be
used
and where they're from along the installation process...
Yes, this is a problem. After source .config (default location), if we
Failed to locate the file, I should prompt to exit instead of going forward.


Now, reading the script I suddenly realise the user doesn't get
prompted
to be able to change the values, you can only set these in the config
files.

I tried hitting Y for fun despite knowing it would crash and burn.
Those
error messages were good so kudos there :)

I think it would make most sense for the user to be prompted for
unset
values with "enter" selecting a sane set of defaults.
Agree and will make improvement on that..
OK, I will give default values for all those variables. If user needs to
change it, he can use a config file to override it. Thanks for the suggestion.


So in summary, I think the right pieces are there in terms of
configuration but the user interaction needs a lot more thought. I
didn't try an actual installation as I don't have a local setup to
allow
it.

For the next review, I'd like an opkg repo to be available somewhere
Lianhao has a testing opkg repo setup on his machine which mimic the
release
package repo and we've been using it test things out

Also I did not attach the opkg source tar ball, so the script can't be run
actually. I plan to dynamically fetch opkg source file when using bitbake
to generate adt-installer tarball. But for reviewing, next time, I will
include the opkg source file tarball in the installer tarball.


Thanks& Regards,
criping


to
test against and for you to provide an installer tarball as an end
user
would receive for people to evaluate.
Yes, and will attach the tar ball with in the next review request

Cheers,

Richard


Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-09 3:49 PM, Darren Hart wrote:
On 12/08/2010 06:35 AM, Bruce Ashfield wrote:
In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.

To accomplish this meta/recipes-kernel/linux/linux-yocto_git.bb
is broken into three parts:
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
Now that the git tree permissions for 2.6.37 are public (not sure how
that impacted this) I am still seeing SRC_REV related parsing errors of
linux-yocto-stable_git.bb. Do you have this working Bruce?
FYI: I've solved this 'for real' now, and I've fixed the SRCREV
issue that I found at the end of my day. I wasn't thinking straight
when I set this up, and I simply neglected to provide valid
SRCREVs for the -stable variant of the kernel. That has allowed
me to remove the SRCREVs from the specific recipes and centralize
the support.

The hack I sent earlier is no longer needed and everything now
looks good. v2 of the series for merge will be out shortly.

Bruce


$ bitbake linux-yocto-stable
NOTE: Out of date cache found, rebuilding...
NOTE: Handling BitBake files: - (0003/0760) [ 0 %]NOTE: <class
'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while
evaluating:
${@bb.fetch.get_srcrev(d)}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${LINUX_VERSION}+git${SRCPV}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${PN}-${EXTENDPE}${PV}-${PR}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${WORKDIR}/linux
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
cd ${S}
if [ -f ${WORKDIR}/defconfig ]; then
defconfig=${WORKDIR}/defconfig
fi

if [ -n "${BOOTSTRAP}" ]; then
kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
else
kbranch=${KBRANCH}
fi

# simply ensures that a branch of the right name has been created
createme ${ARCH} ${kbranch} ${defconfig}
if [ $? -ne 0 ]; then
echo "ERROR. Could not create ${kbranch}"
exit 1
fi

# updates or generates the target description
if [ -n "${KERNEL_FEATURES}" ]; then
addon_features="--features ${KERNEL_FEATURES}"
fi
updateme ${addon_features} ${ARCH} ${WORKDIR}
if [ $? -ne 0 ]; then
echo "ERROR. Could not update ${kbranch}"
exit 1
fi

# executes and modifies the source tree as required
patchme ${kbranch}
if [ $? -ne 0 ]; then
echo "ERROR. Could not modify ${kbranch}"
exit 1
fi

NOTE: Error expanding variable do_patch
ERROR: Please set SRCREV to a valid value while parsing
/home/dvhart/source/poky.git/meta/recipes-kernel/linux/linux-yocto-stable_git.bb

NOTE: Handling BitBake files: / (0311/0760) [40 %]NOTE: <class
'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while
evaluating:
${@bb.fetch.get_srcrev(d)}

Thanks,


Re: PULL] ADT installer script implementation, Liping Ke

Zhang, Jessica
 

Richard Purdie wrote:
Hi Liping, Jessica and team,

On Thu, 2010-12-09 at 17:28 +0800, Ke, Liping wrote:
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/adt_installer_initial
Browse:
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=lke/adt_instal
ler_initial&id=a06769b01d7b18894ad413daa8159f74c90f6c0f


I had a quick look over this and have a few comments. I'm in critical
review mode and don't have a lot of time so please don't take any of
this feedback the wrong way, I just want to give you honest first hand
first time user perception.
Really appreciated your time and feedbacks.


The first thing I read was in the patch was:

+# following are for testing in my machine. it will be moved when
+# going into code repository
+export http_proxy=""
+export HTTP_PROXY=""
+export HTTPS_PROXY=""
+export https_proxy=""
+export ftp_proxy=""
+export FTP_PROXY=""

which it evidently wasn't! ;-)

The rest of that file suggests it probably shouldn't be there
actually?
Sorry for this obvious mistake. Need to do a better job before sending our a
review request next time

I then decided to try it.

cd /
root@rex:/# /rphome/poky/scripts/adt-installer/yocto_installer
/rphome/poky/scripts/adt-installer/yocto_installer: line 207:
.config: No such file or directory [snip lots of similar errors]

So I'd suggest it looks at the location of the main script and then
uses
this to find its config files.

It then found the presetup .config file and took those values as the
defaults. This was not obvious to me, it should perhaps really state
where its getting that config from.

I removed the .config file. That didn't help me so I removed
yocto_installer.conf. This didn't help me much either.
That definitely a bug regarding how to locate .config that we need to
address. As to the different config files, the .config is on purpose non
user editable that's why we set it as hidden file by default. And the
yocto_installer.conf is the customizable config user should change and we
have prompt for the user as regard to the configuration values to be used
and where they're from along the installation process...

Now, reading the script I suddenly realise the user doesn't get
prompted
to be able to change the values, you can only set these in the config
files.

I tried hitting Y for fun despite knowing it would crash and burn.
Those
error messages were good so kudos there :)

I think it would make most sense for the user to be prompted for unset
values with "enter" selecting a sane set of defaults.
Agree and will make improvement on that..

So in summary, I think the right pieces are there in terms of
configuration but the user interaction needs a lot more thought. I
didn't try an actual installation as I don't have a local setup to
allow
it.

For the next review, I'd like an opkg repo to be available somewhere
Lianhao has a testing opkg repo setup on his machine which mimic the release
package repo and we've been using it test things out

to
test against and for you to provide an installer tarball as an end
user
would receive for people to evaluate.
Yes, and will attach the tar ball with in the next review request

Cheers,

Richard


Re: Add extra parameters for qemu script

Zhang, Jessica
 

Garman, Scott A wrote:
On 12/09/2010 12:44 AM, Ke, Liping wrote:
Hi, Scott

The patch is in the attachment for your review. Below is some notes:

1) Basically I wouldn't like to change any logic of the original
code. 2) -serial stdio and -nographic options are removed since
they're be covered by the extra parameters. 3) User input would be
$poky-qemu qemux86 "<-nographic -m 300>" 4) -m input will be checked
still. If it exceeds 128 for arm, it will be changed back to
128M, same logic as before. And after parsing, -m option will
be removed and replaced by Kernel options mem=128M for avoiding some
instability issue.

Generally I modified very few, just add an extra parameters with
least intrusion of
Current logic.

Any comments are welcomed.
I will conduct more test with latest code in parallel.
Hi Criping,

Thanks for the patch. Overall I think this looks good.

However, one thing I feel the need to run by Richard, as he expressed
some preferences with how the poky-qemu script would work with regard
to options.

Richard: Criping's patch would remove the standalone options we had to
the poky-qemu script (e.g, nographic, serial) and instead requires the
user to specify them in one command option which can take any qemu
command switch.

So for example:

poky-qemu qemux86 nographic

would become:

poky-qemu qemux86 "<-nographic>"

The benefit of this is that this allows the user to specify any qemu
option they wish. Previously they were limited by the options we
allowed them to specify (which were quite limited).

I tend to feel that this approach is more flexible, and scales better
than having to support each and every qemu option with our own script
syntax. Is this acceptable, or should we continue to support our own
custom options in addition to Criping's new approach?
Liping and I had the discussion regarding this before she went on taking the
approach. Since we now provide this capability to allow user to provide
their qemu params, then why we still in our qemu scripts isolate certain
qemu params out, which may make things complicated unnecessarily and be more
error prone...

Scott


Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-09 03:49 PM, Darren Hart wrote:
On 12/08/2010 06:35 AM, Bruce Ashfield wrote:
In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.

To accomplish this meta/recipes-kernel/linux/linux-yocto_git.bb
is broken into three parts:
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
Now that the git tree permissions for 2.6.37 are public (not sure how
that impacted this) I am still seeing SRC_REV related parsing errors of
linux-yocto-stable_git.bb. Do you have this working Bruce?
Yep. This is what I found and fixed yesterday. I can't
say that I completely understand my fix, but it is building
all my trees here today, with all the right SRCREVs.

I'm digging a bit more before sending updated patches.

Bruce


$ bitbake linux-yocto-stable
NOTE: Out of date cache found, rebuilding...
NOTE: Handling BitBake files: - (0003/0760) [ 0 %]NOTE: <class
'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while
evaluating:
${@bb.fetch.get_srcrev(d)}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${LINUX_VERSION}+git${SRCPV}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${PN}-${EXTENDPE}${PV}-${PR}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
${WORKDIR}/linux
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid
value while evaluating:
cd ${S}
if [ -f ${WORKDIR}/defconfig ]; then
defconfig=${WORKDIR}/defconfig
fi

if [ -n "${BOOTSTRAP}" ]; then
kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
else
kbranch=${KBRANCH}
fi

# simply ensures that a branch of the right name has been created
createme ${ARCH} ${kbranch} ${defconfig}
if [ $? -ne 0 ]; then
echo "ERROR. Could not create ${kbranch}"
exit 1
fi

# updates or generates the target description
if [ -n "${KERNEL_FEATURES}" ]; then
addon_features="--features ${KERNEL_FEATURES}"
fi
updateme ${addon_features} ${ARCH} ${WORKDIR}
if [ $? -ne 0 ]; then
echo "ERROR. Could not update ${kbranch}"
exit 1
fi

# executes and modifies the source tree as required
patchme ${kbranch}
if [ $? -ne 0 ]; then
echo "ERROR. Could not modify ${kbranch}"
exit 1
fi

NOTE: Error expanding variable do_patch
ERROR: Please set SRCREV to a valid value while parsing
/home/dvhart/source/poky.git/meta/recipes-kernel/linux/linux-yocto-stable_git.bb

NOTE: Handling BitBake files: / (0311/0760) [40 %]NOTE: <class
'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while
evaluating:
${@bb.fetch.get_srcrev(d)}

Thanks,


Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming

Darren Hart <dvhart@...>
 

On 12/08/2010 06:35 AM, Bruce Ashfield wrote:
In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.

To accomplish this meta/recipes-kernel/linux/linux-yocto_git.bb
is broken into three parts:
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
Now that the git tree permissions for 2.6.37 are public (not sure how that impacted this) I am still seeing SRC_REV related parsing errors of linux-yocto-stable_git.bb. Do you have this working Bruce?

$ bitbake linux-yocto-stable
NOTE: Out of date cache found, rebuilding...
NOTE: Handling BitBake files: - (0003/0760) [ 0 %]NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${@bb.fetch.get_srcrev(d)}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${LINUX_VERSION}+git${SRCPV}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${PN}-${EXTENDPE}${PV}-${PR}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${WORKDIR}/linux
NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
cd ${S}
if [ -f ${WORKDIR}/defconfig ]; then
defconfig=${WORKDIR}/defconfig
fi

if [ -n "${BOOTSTRAP}" ]; then
kbranch="yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"
else
kbranch=${KBRANCH}
fi

# simply ensures that a branch of the right name has been created
createme ${ARCH} ${kbranch} ${defconfig}
if [ $? -ne 0 ]; then
echo "ERROR. Could not create ${kbranch}"
exit 1
fi

# updates or generates the target description
if [ -n "${KERNEL_FEATURES}" ]; then
addon_features="--features ${KERNEL_FEATURES}"
fi
updateme ${addon_features} ${ARCH} ${WORKDIR}
if [ $? -ne 0 ]; then
echo "ERROR. Could not update ${kbranch}"
exit 1
fi

# executes and modifies the source tree as required
patchme ${kbranch}
if [ $? -ne 0 ]; then
echo "ERROR. Could not modify ${kbranch}"
exit 1
fi

NOTE: Error expanding variable do_patch
ERROR: Please set SRCREV to a valid value while parsing /home/dvhart/source/poky.git/meta/recipes-kernel/linux/linux-yocto-stable_git.bb
NOTE: Handling BitBake files: / (0311/0760) [40 %]NOTE: <class 'bb.fetch.InvalidSRCREV'>:Please set SRCREV to a valid value while evaluating:
${@bb.fetch.get_srcrev(d)}

Thanks,

--
Darren Hart
Yocto Linux Kernel


Re: Add extra parameters for qemu script

Scott Garman <scott.a.garman@...>
 

On 12/09/2010 12:44 AM, Ke, Liping wrote:
Hi, Scott

The patch is in the attachment for your review. Below is some notes:

1) Basically I wouldn't like to change any logic of the original code.
2) -serial stdio and -nographic options are removed since they're be covered by the extra parameters.
3) User input would be $poky-qemu qemux86 "<-nographic -m 300>"
4) -m input will be checked still. If it exceeds 128 for arm, it will be changed back to
128M, same logic as before. And after parsing, -m option will be removed and replaced by
Kernel options mem=128M for avoiding some instability issue.

Generally I modified very few, just add an extra parameters with least intrusion of
Current logic.

Any comments are welcomed.
I will conduct more test with latest code in parallel.
Hi Criping,

Thanks for the patch. Overall I think this looks good.

However, one thing I feel the need to run by Richard, as he expressed some preferences with how the poky-qemu script would work with regard to options.

Richard: Criping's patch would remove the standalone options we had to the poky-qemu script (e.g, nographic, serial) and instead requires the user to specify them in one command option which can take any qemu command switch.

So for example:

poky-qemu qemux86 nographic

would become:

poky-qemu qemux86 "<-nographic>"

The benefit of this is that this allows the user to specify any qemu option they wish. Previously they were limited by the options we allowed them to specify (which were quite limited).

I tend to feel that this approach is more flexible, and scales better than having to support each and every qemu option with our own script syntax. Is this acceptable, or should we continue to support our own custom options in addition to Criping's new approach?

Scott

--
Scott Garman
Embedded Linux Distro Engineer - Yocto Project


Re: PULL] ADT installer script implementation, Liping Ke

Richard Purdie <rpurdie@...>
 

Hi Liping, Jessica and team,

On Thu, 2010-12-09 at 17:28 +0800, Ke, Liping wrote:
Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/adt_installer_initial
Browse: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=lke/adt_installer_initial&id=a06769b01d7b18894ad413daa8159f74c90f6c0f

I had a quick look over this and have a few comments. I'm in critical
review mode and don't have a lot of time so please don't take any of
this feedback the wrong way, I just want to give you honest first hand
first time user perception.

The first thing I read was in the patch was:

+# following are for testing in my machine. it will be moved when
+# going into code repository
+export http_proxy=""
+export HTTP_PROXY=""
+export HTTPS_PROXY=""
+export https_proxy=""
+export ftp_proxy=""
+export FTP_PROXY=""

which it evidently wasn't! ;-)

The rest of that file suggests it probably shouldn't be there actually?

I then decided to try it.

cd /
root@rex:/# /rphome/poky/scripts/adt-installer/yocto_installer
/rphome/poky/scripts/adt-installer/yocto_installer: line 207: .config: No such file or directory
[snip lots of similar errors]

So I'd suggest it looks at the location of the main script and then uses
this to find its config files.

It then found the presetup .config file and took those values as the
defaults. This was not obvious to me, it should perhaps really state
where its getting that config from.

I removed the .config file. That didn't help me so I removed
yocto_installer.conf. This didn't help me much either.

Now, reading the script I suddenly realise the user doesn't get prompted
to be able to change the values, you can only set these in the config
files.

I tried hitting Y for fun despite knowing it would crash and burn. Those
error messages were good so kudos there :)

I think it would make most sense for the user to be prompted for unset
values with "enter" selecting a sane set of defaults.

So in summary, I think the right pieces are there in terms of
configuration but the user interaction needs a lot more thought. I
didn't try an actual installation as I don't have a local setup to allow
it.

For the next review, I'd like an opkg repo to be available somewhere to
test against and for you to provide an installer tarball as an end user
would receive for people to evaluate.

Cheers,

Richard


Re: [PATCH 0/3] linux-yocto: refactor recipes and update the kernel

Elizabeth Flanagan <elizabeth.flanagan@...>
 

On 12/09/2010 07:56 AM, Bruce Ashfield wrote:
On 10-12-08 09:35 AM, Bruce Ashfield wrote:
Richard,

Consider these patches for merging. I've been building and working
with these for 2 weeks now, and while they aren't perfect, they
work and we need more eyes on 2.6.37.
Does anyone with the right admin privs have time to look
into this ?

> git clone git://git.pokylinux.org/linux-yocto-2.6.37
fatal: destination path 'linux-yocto-2.6.37' already exists and is not
an empty directory.
yow-bashfiel-d2 [/tmp]> rm -rf linux-yocto-2.6.37/
yow-bashfiel-d2 [/tmp]> git clone git://git.pokylinux.org/linux-yocto-2.6.37
Initialized empty Git repository in /tmp/linux-yocto-2.6.37/.git/
fatal: The remote end hung up unexpectedly
yow-bashfiel-d2 [/tmp]> git clone
git://git.pokylinux.org/linux-2.6-windriver
Initialized empty Git repository in /tmp/linux-2.6-windriver/.git/
^Cmote: Counting objects: 125026

------

In other words, the 2.6.37 repo is only reachable by a ssh
based clone :)

When I get that working, I can fixup the SRCREV issue and
resubmit this for merge.

Cheers,

Bruce
Fixed this. Due to the repo not being public.

-b


Re: [PATCH 0/3] linux-yocto: refactor recipes and update the kernel

Bruce Ashfield <bruce.ashfield@...>
 

On 10-12-08 09:35 AM, Bruce Ashfield wrote:
Richard,

Consider these patches for merging. I've been building and working
with these for 2 weeks now, and while they aren't perfect, they
work and we need more eyes on 2.6.37.
Does anyone with the right admin privs have time to look
into this ?

git clone git://git.pokylinux.org/linux-yocto-2.6.37
fatal: destination path 'linux-yocto-2.6.37' already exists and is not an empty directory.
yow-bashfiel-d2 [/tmp]> rm -rf linux-yocto-2.6.37/
yow-bashfiel-d2 [/tmp]> git clone git://git.pokylinux.org/linux-yocto-2.6.37
Initialized empty Git repository in /tmp/linux-yocto-2.6.37/.git/
fatal: The remote end hung up unexpectedly
yow-bashfiel-d2 [/tmp]> git clone git://git.pokylinux.org/linux-2.6-windriver
Initialized empty Git repository in /tmp/linux-2.6-windriver/.git/
^Cmote: Counting objects: 125026

------

In other words, the 2.6.37 repo is only reachable by a ssh
based clone :)

When I get that working, I can fixup the SRCREV issue and
resubmit this for merge.

Cheers,

Bruce


What we get is the following:

- factoring of the code into some reusable routines in the form
of a linux-yocto bbclass. The -stable, -devel and libc headers
recipes are all using this common code

- A new branching scheme for the 2.6.37 kernel that generalizes
the branch names and shows their hierarchy. The tools that
process the kernel needed a lot of 'unlearning' about the
old structure (this took a lot of my time working on this).

If this needs to be tweaked more, we can do it later, since
the big changes are done and agreed on, and we can't delay
scaling this out to more boards much longer.

- A -stable recipe that continues to build the 2.6.34 kernel
and a move of the main recipe to track the development
2.6.37-rc5 tree. The qemu* targets have their defaults
changed to 2.6.37-rc, while the hardware targets remain
on 2.6.34 for a bit longer. To ease the switch over, I
put the SRCREVs for 2.6.37 into the recipe itself. We
can move these as .37 becomes the default.

- perf is moved into a linux-tools.inc, we can add more to
this and re-use it more easily from here

- BSP boostrapping is streamlined (docs to follow).

The temporary commenting of the preferred libc-headers provider
was intentional. There is something strange happening when
headers are generated for 2.6.34 that was breaking libc builds.
To avoid holding up this series, we'll go with the default
libc headers for a short while.

I've built and booted all the qemu* targets on 2.6.37
(minimal and sato), I've built most of the hardware
targets. I noticed some strangeness with the mouse on
ARM, and that will need to be looked at further. I've done
some audits on the kernel configuration in 2.6.37, and
while it looks sane, full BSP testing will tell us if
anything major changed (that I missed).

If there are better suggestions on how we can stage and
get mileage on this code, I'm all ears, but this is a kernel
uprev, so I expect some issues (there always is even though
I've done plenty of these). If we don't want anything
destabilizing in the tree, I'm fine with this and we just
need to come up with a plan.

What remains (I'm only one person!):

- BSP porting and full BSP testing
- Investigation into the libc-headers issue
- Continued cleanup
- Feature merging into 2.6.37 (lttng, yaffs, etc)

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: zedd/kernel
Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Thanks,
Bruce Ashfield<bruce.ashfield@...>
---


Bruce Ashfield (3):
yocto-kernel: factor common routes, update to 2.6.37 and branch
renaming
linux-libc-headers-yocto: use common linux-yocto routines
qemu: update arm timer handling

meta-emenlow/conf/machine/emenlow.conf | 3 +-
meta/classes/kernel-yocto.bbclass | 202 +++++++++++++++++
.../conf/distro/include/poky-default-revisions.inc | 2 +-
meta/conf/machine/atom-pc.conf | 3 +-
meta/conf/machine/beagleboard.conf | 3 +-
meta/conf/machine/include/qemu.inc | 1 +
meta/conf/machine/mpc8315e-rdb.conf | 3 +-
meta/conf/machine/routerstationpro.conf | 3 +-
.../qemu-0.12.4/arm_timer-fix-oneshot-mode.patch | 32 +++
.../arm_timer-reload-timer-when-enabled.patch | 40 ++++
meta/recipes-devtools/qemu/qemu_0.12.4.bb | 4 +-
.../linux-libc-headers-yocto_git.bb | 25 +--
meta/recipes-kernel/linux/linux-tools.inc | 19 ++
.../recipes-kernel/linux/linux-yocto-stable_git.bb | 41 ++++
meta/recipes-kernel/linux/linux-yocto.inc | 23 ++
meta/recipes-kernel/linux/linux-yocto_git.bb | 232 +++-----------------
16 files changed, 415 insertions(+), 221 deletions(-)
create mode 100644 meta/classes/kernel-yocto.bbclass
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-fix-oneshot-mode.patch
create mode 100644 meta/recipes-devtools/qemu/qemu-0.12.4/arm_timer-reload-timer-when-enabled.patch
create mode 100644 meta/recipes-kernel/linux/linux-tools.inc
create mode 100644 meta/recipes-kernel/linux/linux-yocto-stable_git.bb
create mode 100644 meta/recipes-kernel/linux/linux-yocto.inc

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


PULL] ADT installer script implementation, Liping Ke

Ke, Liping <liping.ke@...>
 

Hi, Saul

This pull request includes initial ADT(Yocto Application Development Tools) installer script implementation.

Pull URL: git://git.pokylinux.org/poky-contrib.git
Branch: lke/adt_installer_initial
Browse: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=lke/adt_installer_initial&id=a06769b01d7b18894ad413daa8159f74c90f6c0f


Thanks,
criping



Add initial yocto adt installer scriptlke/adt_installer_initial
Below patches are for installing Yocto Application Development Tools.
opkg files include both 32 bit and 64 bit installation machine.
Installer entry script file is yocto_installer. A hidden .config files
are for holding parameters which are unlikely to be changed by end users

Signed-off-by: Liping Ke <liping.ke@...>
Signed-off-by: Jessica Zhang<jessica.zhang@...>
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r-- scripts/adt-installer/.config 35
-rw-r--r-- scripts/adt-installer/opkg-sdk-i586.conf 17
-rw-r--r-- scripts/adt-installer/opkg-sdk-x86_64.conf 17
-rw-r--r-- scripts/adt-installer/util 70
-rwxr-xr-x scripts/adt-installer/yocto_installer 250
-rw-r--r-- scripts/adt-installer/yocto_installer.conf 32
-rwxr-xr-x scripts/adt-installer/yocto_installer_internal 222
7 files changed, 643 insertions, 0 deletions


Add extra parameters for qemu script

Ke, Liping <liping.ke@...>
 

Hi, Scott

The patch is in the attachment for your review. Below is some notes:

1) Basically I wouldn't like to change any logic of the original code.
2) -serial stdio and -nographic options are removed since they're be covered by the extra parameters.
3) User input would be $poky-qemu qemux86 "<-nographic -m 300>"
4) -m input will be checked still. If it exceeds 128 for arm, it will be changed back to
128M, same logic as before. And after parsing, -m option will be removed and replaced by
Kernel options mem=128M for avoiding some instability issue.

Generally I modified very few, just add an extra parameters with least intrusion of
Current logic.

Any comments are welcomed.
I will conduct more test with latest code in parallel.

Thanks a lot for your help!
criping


Re: [Bug 246987] [tcf] Would be nice to have Shell(Terminal) subsystem over TCF

Zhang, Jessica
 

Yeh... It's quite a milestone since it's our first contribution to the
community...

Cheers,
Jessica
Ke, Liping wrote:

Hi, Jessica

FYI.
TCF terminal/shell java code part is now in upstream.

Thanks& Regards,
criping

-----Original Message-----
From: bugzilla-daemon@...
[mailto:bugzilla-daemon@...] Sent: Wednesday, December 08,
2010 11:54 PM
To: Ke, Liping
Subject: [Bug 246987] [tcf] Would be nice to have Shell(Terminal)
subsystem over TCF

https://bugs.eclipse.org/bugs/show_bug.cgi?id=246987
Product/Component: Target Management / TCF

Anna Dushistova <anna_dushistova@...> changed:

What |Removed |Added
-----------------------------------------------------------------------
-----
Attachment #184447| |iplog+
Flag| |

--- Comment #82 from Anna Dushistova <anna_dushistova@...>
2010- 12-08 10:53:35 EST --- (From update of attachment 184447)
Applied the patch with the copyright changes requested by Eclipse
Legal.

--
Configure bugmail:
https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Re: [Bug 246987] [tcf] Would be nice to have Shell(Terminal) subsystem over TCF

Tian, Kevin <kevin.tian@...>
 

that's a great news. So now all of our eclipse enhancements are in upstream!

Thanks
Kevin

From: Ke, Liping
Sent: Thursday, December 09, 2010 9:44 AM

Hi, Jessica

FYI.
TCF terminal/shell java code part is now in upstream.

Thanks& Regards,
criping

-----Original Message-----
From: bugzilla-daemon@... [mailto:bugzilla-daemon@...]
Sent: Wednesday, December 08, 2010 11:54 PM
To: Ke, Liping
Subject: [Bug 246987] [tcf] Would be nice to have Shell(Terminal)
subsystem over TCF

https://bugs.eclipse.org/bugs/show_bug.cgi?id=246987
Product/Component: Target Management / TCF

Anna Dushistova <anna_dushistova@...> changed:

What |Removed |Added
-----------------------------------------------------------------------
-----
Attachment #184447| |iplog+
Flag| |

--- Comment #82 from Anna Dushistova <anna_dushistova@...> 2010-
12-08 10:53:35 EST ---
(From update of attachment 184447)
Applied the patch with the copyright changes requested by Eclipse Legal.

--
Configure bugmail:
https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


FW: [Bug 246987] [tcf] Would be nice to have Shell(Terminal) subsystem over TCF

Ke, Liping <liping.ke@...>
 

Hi, Jessica

FYI.
TCF terminal/shell java code part is now in upstream.

Thanks& Regards,
criping

-----Original Message-----
From: bugzilla-daemon@... [mailto:bugzilla-daemon@...]
Sent: Wednesday, December 08, 2010 11:54 PM
To: Ke, Liping
Subject: [Bug 246987] [tcf] Would be nice to have Shell(Terminal)
subsystem over TCF

https://bugs.eclipse.org/bugs/show_bug.cgi?id=246987
Product/Component: Target Management / TCF

Anna Dushistova <anna_dushistova@...> changed:

What |Removed |Added
-----------------------------------------------------------------------
-----
Attachment #184447| |iplog+
Flag| |

--- Comment #82 from Anna Dushistova <anna_dushistova@...> 2010-
12-08 10:53:35 EST ---
(From update of attachment 184447)
Applied the patch with the copyright changes requested by Eclipse Legal.

--
Configure bugmail:
https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Re: [PATCH 1/3] yocto-kernel: factor common routes, update to 2.6.37 and branch renaming

Darren Hart <dvhart@...>
 

On 12/08/2010 12:20 PM, Bruce Ashfield wrote:
On 10-12-08 09:35 AM, Bruce Ashfield wrote:
In order to extend and create more kernel recipes based on the
supported yocto kernel common routines need to be placed in
re-usable blocks.
There may be a minor problem with this, stay tuned.

I just had a strange failure when I built the 2.6.37
kernel .. it blew up in the SRCREVs for the -stable
kernel. Looking into it.
I was just about to report this :-). I also see these sorts of issues when working with other kernel recipes, and I haven't gotten to the bottom of it yet. I see this with the linux-linaro for instance (the error occurs while parsing the linux-yocto_git.bb - it was linux-wrs_git.bb at the time).

Please let us know if what you find if you get the bottom of it first.

--
Darren Hart
Yocto Linux Kernel