[U-Boot-Users] [PATCH] fix the ARM memory layout

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Anders Larsen]

Hi,

here's a fresh version of my rather intrusive patch from the 17.th sept.
to rearrange the ARM memory layout to bring it in line with the README.

This has the positive side-effect of actually allow U-Boot to run on
PXA- and IXP-based targets; the current implementation sets up the heap
using bogus addresses causing u-boot to crash (this even applies to the
recently added board "ixdp425").

This patch doesn't go all the way, though, since doing away with the
board-specific setting of TEXT_BASE would require the code to be
position-independent, which at least the cpu initialization code in
cpu/*/start.S is _not_.

CHANGELOG:
   Bring the ARM memory layout in line with the documentation.

Cheers
 Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot.arm-memory.patch.gz
Type: application/x-gzip
Size: 9520 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20031112/c4b90e69/attachment.bin 

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Kyle Harris]

On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:

> Hi,
>
> here's a fresh version of my rather intrusive patch from the 17.th sept.
> to rearrange the ARM memory layout to bring it in line with the README.
>
> This has the positive side-effect of actually allow U-Boot to run on
> PXA- and IXP-based targets; the current implementation sets up the heap
> using bogus addresses causing u-boot to crash (this even applies to the
> recently added board "ixdp425").

I don't disagree that memory layout for ARM is broken. But, I've never seen a 
crash on any of my Xscale boards, including a couple of new ones based on 
ixdp425 and cradle. 

Kyle.

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Anders Larsen]

Kyle Harris <kharris@nexus-tech.net> schreibt:
>
>On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:
>
>> This has the positive side-effect of actually allow U-Boot to run on
>> PXA- and IXP-based targets; the current implementation sets up the heap
>> using bogus addresses causing u-boot to crash (this even applies to the
>> recently added board "ixdp425").
>
>I don't disagree that memory layout for ARM is broken. But, I've never
>seen a 
>crash on any of my Xscale boards, including a couple of new ones based on 
>ixdp425 and cradle. 

Hi Kyle,

Do you by any chance happen to have RAM at and around address
0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work,
for the reasons Richard already gave.
(see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)

(BTW, I recognize you've contributed significantly to the PXA
implementation I'm relying on and I'd like to thank you for that).

Cheers
 Anders

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Kyle Harris]

Hi All,

On Thursday 13 November 2003 04:14 am, Anders Larsen wrote:

> Kyle Harris <kharris@nexus-tech.net> schreibt:
> >On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:
> >> This has the positive side-effect of actually allow U-Boot to run on
> >> PXA- and IXP-based targets; the current implementation sets up the heap
> >> using bogus addresses causing u-boot to crash (this even applies to the
> >> recently added board "ixdp425").
> >
> >I don't disagree that memory layout for ARM is broken. But, I've never
> >seen a
> >crash on any of my Xscale boards, including a couple of new ones based on
> >ixdp425 and cradle.
>
> Hi Kyle,
>
> Do you by any chance happen to have RAM at and around address
> 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work,
> for the reasons Richard already gave.
> (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)

Yeh, I don't doubt there is a problem. I guess I need to take a closer look 
and see why it works. But finding the time to work on something that actually 
already works is difficult...(got plenty of stuff that doesn't work to keep 
me busy).

> (BTW, I recognize you've contributed significantly to the PXA
> implementation I'm relying on and I'd like to thank you for that).

You're welcome. But all I did was put the framework in place so that you and 
Richard and others can make it work correctly ;)

Kyle.

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Kyle Harris]

On Thursday 13 November 2003 09:19 am, Kyle Harris wrote:

> > Do you by any chance happen to have RAM at and around address
> > 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work,
> > for the reasons Richard already gave.
> > (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
>
> Yeh, I don't doubt there is a problem. I guess I need to take a closer look
> and see why it works. 

I think the mystery is solved. I just updated my latest pxa to 1.0.0. It was 
based on 0.2.3 and the ixp port was based on 0.4.0. Early versions of the 
code, while not perfect, did run. Definitely a problem with the later stuff 
without proper patches (thanks for the patches).

Kyle.

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Anders Larsen]

Kyle Harris <kharris@nexus-tech.net> schreibt:
>
>On Thursday 13 November 2003 09:19 am, Kyle Harris wrote:
>
>> > Do you by any chance happen to have RAM at and around address
>> > 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work,
>> > for the reasons Richard already gave.
>> > (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
>>
>> Yeh, I don't doubt there is a problem. I guess I need to take a closer
>look
>> and see why it works. 
>
>I think the mystery is solved. I just updated my latest pxa to 1.0.0. It
>was 
>based on 0.2.3 and the ixp port was based on 0.4.0. Early versions of the 
>code, while not perfect, did run. Definitely a problem with the later
>stuff 
>without proper patches (thanks for the patches).

Hi Wolfgang,

what's needed to make the patch worthy of inclusion?
I know the patch doesn't go all the way you want, but IMHO we need
several steps for that in order not to wreak too much havoc.

Cheers
 Anders

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001ea0e0004c4e48001e6497.1ea0ee@rea.de> you wrote:
> 
> what's needed to make the patch worthy of inclusion?

More time :-(

> I know the patch doesn't go all the way you want, but IMHO we need
> several steps for that in order not to wreak too much havoc.

You are right, and I am perfectly willing to add  this,  but  at  the
moment  I'm caught in some other activities. I hope to find some more
time for U-Boot next week.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Just go with the flow control, roll with the crunches, and, when  you
get a prompt, type like hell.

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Wolfgang Denk]

In message <fc.004c4e48001e6497004c4e48001e6497.1e64ae@rea.de> you wrote:
> 
> here's a fresh version of my rather intrusive patch from the 17.th sept.
> to rearrange the ARM memory layout to bring it in line with the README.

Sorry, I'm working through my backlog sequentuially,  and  I  already
added  the  other  patch.  Can  you please check your current version
against current top-of-tree in CVS and provide a new diff?

Thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"'Tis true, 'tis pity, and pity 'tis 'tis true."
    - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Anders Larsen]

On Sun, 07 Dec 2003 01:17:08 +0100 Wolfgang Denk <wd@denx.de> wrote:

> In message <fc.004c4e48001e6497004c4e48001e6497.1e64ae@rea.de> you wrote:
> > 
> > here's a fresh version of my rather intrusive patch from the 17.th sept.
> > to rearrange the ARM memory layout to bring it in line with the README.
> 
> Sorry, I'm working through my backlog sequentuially,  and  I  already
> added  the  other  patch.  Can  you please check your current version
> against current top-of-tree in CVS and provide a new diff?

Hi Wolfgang,

sure, only I can't say when I'll be able to do it, since
cvs.sourceforge.net is currently rejecting connections  :-(

Cheers
 Anders

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Anders Larsen]

Wolfgang Denk <wd@denx.de> schreibt:
>In message <fc.004c4e48001e6497004c4e48001e6497.1e64ae@rea.de> you wrote:
>> 
>> here's a fresh version of my rather intrusive patch from the 17.th sept.
>> to rearrange the ARM memory layout to bring it in line with the README.
>
>Sorry, I'm working through my backlog sequentuially,  and  I  already
>added  the  other  patch.  Can  you please check your current version
>against current top-of-tree in CVS and provide a new diff?

Hi Wolfgang,

the attached patch (against CVS 2004-01-08) fixes the rest of the ARM
stuff I had in the pipe.

In particular, the abort-stack is now set up in the correct RAM area
(which I had neglected in my previous patches), and the BSS is zeroed
out as it should be (which most previous ARM implementations had
neglected).

Furthermore, the magic variables 'armboot_end' and 'armboot_end_data'
of the linker scripts are replaced by '__bss_start' and '_end', resp.,
which is a further step to eliminate unnecessary differences between
the implementation of the CPU architectures.

Compilation tested with MAKEALL arm, functionality only tested on my
PXA-based board.

CHANGELOG:
   Fix the ARM memory layout.

Cheers
 Anders

(Patch gzipped due to size constraints on the list)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-cvs.arm-memory.patch.gz
Type: application/x-gzip
Size: 6958 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040109/5349a577/attachment.bin 

[U-Boot-Users] [PATCH] fix the ARM memory layout

[Wolfgang Denk]

Dear Anders,

in message <fc.004c4e48001fbb1a3b9aca00884cdb6e.1fbb43@rea.de> you wrote:
> 
> the attached patch (against CVS 2004-01-08) fixes the rest of the ARM
> stuff I had in the pipe.

Thanks a lot, added.

> Compilation tested with MAKEALL arm, functionality only tested on my
> PXA-based board.

I tested it on the SMDK2400 and TRAB boards with several memory  con-
figurations. Workes fine. Thanks a lot!!

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
In theory, there is no difference between  theory  and  practice.  In
practice, however, there is.

[U-Boot-Users] PCI, Ethernet, IXDP425

[Ara Avanesyan]

Hi all,

I've just got my ixdp425 evaluation board and tried u-boot on it.

I have a PCI Ethernet card on the board. I need to connect to the network 
from u-boot via this device.

Are there any ways to do so? What I will have to do to enable this support? 
Or at least are there ANY PCI Ethernet drivers in u-boot?

Thanks for your help,
Ara

[U-Boot-Users] PCI, Ethernet, IXDP425

[Wolfgang Denk]

In message <002d01c4f7bf$e180b7e0$1000000a@araav> you wrote:
> 
> I have a PCI Ethernet card on the board. I need to connect to the network 
> from u-boot via this device.

Just do it.

> Are there any ways to do so? What I will have to do to enable this support? 
> Or at least are there ANY PCI Ethernet drivers in u-boot?

How about checking the code before posting?

Yes, there are.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Ara Avanesyan]

Thanks for so helpful and informative reply.

configs/ixdp425.h, line 59:
#define CONFIG_COMMANDS         (CONFIG_CMD_DFL & ~CFG_CMD_NET)

So how about checking the code before posting?;-)

Thanks,
Ara

----- Original Message ----- 
From: "Wolfgang Denk" <wd@denx.de>
To: "Ara Avanesyan" <araav@hylink.am>
Cc: <u-boot-users@lists.sourceforge.net>
Sent: Wednesday, January 12, 2005 2:40 AM
Subject: Re: [U-Boot-Users] PCI, Ethernet, IXDP425


> In message <002d01c4f7bf$e180b7e0$1000000a@araav> you wrote:
>>
>> I have a PCI Ethernet card on the board. I need to connect to the network
>> from u-boot via this device.
>
> Just do it.
>
>> Are there any ways to do so? What I will have to do to enable this 
>> support?
>> Or at least are there ANY PCI Ethernet drivers in u-boot?
>
> How about checking the code before posting?
>
> Yes, there are.
>
> Best regards,
>
> Wolfgang Denk
>
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Confound these ancestors.... They've stolen our best ideas!"
> - Ben Jonson
> 

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Rodel Miguel]

Ara,

If you see the driver for your PCI Ethernet card on the drivers
directory, then you'll be fine.  However, you may need to write your
own driver if it does not exist.  So check on the drivers directory
first and then, if it exists, write the appropriate CFG parameter on
the configs/ixdp425.h file.  try removing the ~CFG_CMD_NET, and other
parameters that the driver might require.

Regards,
Rodel

P.S. Anyone working on ethernet MAC's with MII-only interfaces??? I'm
actually lost... Please help.

On Wed, 12 Jan 2005 10:18:28 +0400, Ara Avanesyan <araav@hylink.am> wrote:
> Thanks for so helpful and informative reply.
> 
> configs/ixdp425.h, line 59:
> #define CONFIG_COMMANDS         (CONFIG_CMD_DFL & ~CFG_CMD_NET)
> 
> So how about checking the code before posting?;-)
> 
> Thanks,
> Ara
> 
> ----- Original Message -----
> From: "Wolfgang Denk" <wd@denx.de>
> To: "Ara Avanesyan" <araav@hylink.am>
> Cc: <u-boot-users@lists.sourceforge.net>
> Sent: Wednesday, January 12, 2005 2:40 AM
> Subject: Re: [U-Boot-Users] PCI, Ethernet, IXDP425
> 
> > In message <002d01c4f7bf$e180b7e0$1000000a@araav> you wrote:
> >>
> >> I have a PCI Ethernet card on the board. I need to connect to the network
> >> from u-boot via this device.
> >
> > Just do it.
> >
> >> Are there any ways to do so? What I will have to do to enable this
> >> support?
> >> Or at least are there ANY PCI Ethernet drivers in u-boot?
> >
> > How about checking the code before posting?
> >
> > Yes, there are.
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> > "Confound these ancestors.... They've stolen our best ideas!"
> > - Ben Jonson
> >
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Ara Avanesyan]

Thanks Rodel,

I think we'll switch to one supported by u-boot right now, as poritng will 
take a long time.
Ok, I'm going to play with u-boot's net paramters.

Thanks,
Ara

----- Original Message ----- 
From: "Rodel Miguel" <rodelfmiguel@gmail.com>
To: "Ara Avanesyan" <araav@hylink.am>
Cc: "Wolfgang Denk" <wd@denx.de>; <u-boot-users@lists.sourceforge.net>
Sent: Wednesday, January 12, 2005 10:41 AM
Subject: Re: [U-Boot-Users] Re: PCI, Ethernet, IXDP425


> Ara,
>
> If you see the driver for your PCI Ethernet card on the drivers
> directory, then you'll be fine.  However, you may need to write your
> own driver if it does not exist.  So check on the drivers directory
> first and then, if it exists, write the appropriate CFG parameter on
> the configs/ixdp425.h file.  try removing the ~CFG_CMD_NET, and other
> parameters that the driver might require.
>
> Regards,
> Rodel
>
> P.S. Anyone working on ethernet MAC's with MII-only interfaces??? I'm
> actually lost... Please help.
>
> On Wed, 12 Jan 2005 10:18:28 +0400, Ara Avanesyan <araav@hylink.am> wrote:
>> Thanks for so helpful and informative reply.
>>
>> configs/ixdp425.h, line 59:
>> #define CONFIG_COMMANDS         (CONFIG_CMD_DFL & ~CFG_CMD_NET)
>>
>> So how about checking the code before posting?;-)
>>
>> Thanks,
>> Ara
>>
>> ----- Original Message -----
>> From: "Wolfgang Denk" <wd@denx.de>
>> To: "Ara Avanesyan" <araav@hylink.am>
>> Cc: <u-boot-users@lists.sourceforge.net>
>> Sent: Wednesday, January 12, 2005 2:40 AM
>> Subject: Re: [U-Boot-Users] PCI, Ethernet, IXDP425
>>
>> > In message <002d01c4f7bf$e180b7e0$1000000a@araav> you wrote:
>> >>
>> >> I have a PCI Ethernet card on the board. I need to connect to the 
>> >> network
>> >> from u-boot via this device.
>> >
>> > Just do it.
>> >
>> >> Are there any ways to do so? What I will have to do to enable this
>> >> support?
>> >> Or at least are there ANY PCI Ethernet drivers in u-boot?
>> >
>> > How about checking the code before posting?
>> >
>> > Yes, there are.
>> >
>> > Best regards,
>> >
>> > Wolfgang Denk
>> >
>> > --
>> > Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>> > "Confound these ancestors.... They've stolen our best ideas!"
>> > - Ben Jonson
>> >
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
> 

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Ing.Gianfranco Morandi]

> P.S. Anyone working on ethernet MAC's with MII-only interfaces??? I'm
> actually lost... Please help.

I have tried to approach the ethernet driver development for IXP425 NPE, but
unfortunately there are some problems with the Intel library and the APIs
that are not well described.
The source code seems to be not completely available as well.

Actually we have stopped the driver development on u-boot by accepting only
to use the NPE with linux (which still requires a big part of library to be
resident to work properly), but we are ready to evaluate any possible
cooperation to support this development.

regards

Gianfranco

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Wolfgang Denk]

In message <001001c4f86e$882391e0$1000000a@araav> you wrote:
> Thanks for so helpful and informative reply.

You are welcome.

> configs/ixdp425.h, line 59:
> #define CONFIG_COMMANDS         (CONFIG_CMD_DFL & ~CFG_CMD_NET)
> 
> So how about checking the code before posting?;-)

So what? The "CONFIG_" part in this define is  intended  to  indicate
that  this is a user configurable setting - one user does not need or
want network support, another may want it.

What exactly are you complaining  about?  That  you  don't  find  the
system pre-configured to your specifc wishes?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Documentation is like sex: when it is good, it is  very,  very  good;
and when it is bad, it is better than nothing.         - Dick Brandon

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Ara Avanesyan]

>
> What exactly are you complaining  about?  That  you  don't  find  the
> system pre-configured to your specifc wishes?
>
have i complained in my posts? although there is one: that the ixp port does 
not support pci support at all though you said "Just do it" to my
> I have a PCI Ethernet card on the board. I need to connect to the network
> from u-boot via this device.

btw, if you don't know the answer to questions, just don't answer:) there 
are many other users in the list ;)

anyways, thanks,
Ara

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Anders Larsen]

"Ara Avanesyan" <araav@hylink.am> schreibt:
>have i complained in my posts? although there is one: that the ixp port
>does 
>not support pci support at all though you said "Just do it" to my

The ixdp425 port does not _include_ PCI support; that does not mean PCI
is not supported.

>> I have a PCI Ethernet card on the board. I need to connect to the
>network
>> from u-boot via this device.

You still haven't mentioned which one...
(BTW, there are truckloads of supported PCI Ethernet cards in U-Boot)
>
>btw, if you don't know the answer to questions, just don't answer:) there 
>are many other users in the list ;)

You obviously haven't done your homework (i.e. read the README),
otherwise you would have known that Wolfgang is the project leader.

Cheers
 Anders

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Wolfgang Denk]

In message <004201c4f889$b1b825a0$1000000a@araav> you wrote:
>
> have i complained in my posts? although there is one: that the ixp port does 
> not support pci support at all though you said "Just do it" to my

You sounded a bit aggressive to me, and you are wrong again: The  IXP
port does support PCI:



> > I have a PCI Ethernet card on the board. I need to connect to the network
> > from u-boot via this device.
> 
> btw, if you don't know the answer to questions, just don't answer:) there 
> are many other users in the list ;)

Here you go again. You should not insult people who you ask for help.
I know EXACTLY what I'm speaking of. See here:

	---------------------
	PatchSet 1138 
	Date: 2005/01/09 17:12:27
	Author: wdenk
	Branch: HEAD
	Tag: (none)  
	Log:
	* Patch by Jon Loeliger, 02 Sep 2004:
	  Reset monitor size back to 256 so environment can be written 
	  to flash on MPC85xx ADS and CDS releases.

	* Patch by Paolo Broggini, 02 Sep 2004:
	  Make BSS clearing on ARM systems more robust

	* Patch by Yue Hu and Joe, 01 Sep 2004:
===>>>	  - add PCI support for ixp425; 
===>>>	  - add EEPRO100 suppor tfor ixdp425 board.
	  
	* Fix problem with protected sector detection in driver/cfi_flash.c
	  
	Members: 
		CHANGELOG:1.406->1.407 
		board/ixdp425/ixdp425.c:1.3->1.4 
		board/xilinx/xilinx_iic/iic_adapter.c:1.2->1.3 
		cpu/arm720t/start.S:1.9->1.10 
		cpu/arm920t/start.S:1.9->1.10 
		cpu/arm925t/start.S:1.7->1.8 
		cpu/arm926ejs/start.S:1.8->1.9 
		cpu/at91rm9200/start.S:1.7->1.8 
		cpu/ixp/Makefile:1.1->1.2 
		cpu/ixp/cpu.c:1.2->1.3 
		cpu/ixp/pci.c:INITIAL->1.1 
		cpu/ixp/start.S:1.4->1.5 
		cpu/lh7a40x/start.S:1.1->1.2 
		cpu/pxa/start.S:1.6->1.7 
		cpu/sa1100/start.S:1.6->1.7 
		drivers/cfi_flash.c:1.15->1.16 
		drivers/pci.c:1.10->1.11 
		include/version.h:1.25->1.26 
		include/asm-arm/arch-ixp/ixp425pci.h:INITIAL->1.1 
		include/configs/MPC8540ADS.h:1.6->1.7 
		include/configs/MPC8541CDS.h:1.3->1.4 
		include/configs/MPC8555CDS.h:1.3->1.4 
		include/configs/MPC8560ADS.h:1.6->1.7 
		include/configs/ixdp425.h:1.3->1.4 
		lib_arm/board.c:1.30->1.31 
	---------------------

Seems it's you who has no clue.

I don't blame you for that - I cannot expect that you spend  so  much
time with U-Boot like me, but then you should rather think twice what
you write.

I cannot help you if you continue to ignore what I'm trying  to  tell
you.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
They say a little knowledge is a dangerous thing,  but it is not  one
half so bad as a lot of ignorance.   - Terry Pratchett, _Equal Rites_

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Wolfgang Denk]

In message <fc.004c4e48002d477a3b9aca00d3c0d25e.2d478e@rea.de> you wrote:
>
> The ixdp425 port does not _include_ PCI support; that does not mean PCI
> is not supported.

It does. See my previous message.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Motto of the Electrical Engineer: Working computer hardware is a  lot
like an erect penis: it stays up as long as you don't fuck with it.

[U-Boot-Users] Re: PCI, Ethernet, IXDP425

[Ara Avanesyan]

Sorry for being so rude. I shouldn't write like that, i just got somewhat 
uncomfortable when I asked a help for doing something and you said "just do 
it".

omg, the PCI support was added like three days ago, I'm now feeling so 
lucky.
(I spent all my day reinventing the wheel). I'm now going to try it out.
I really hope it will work.

Hey, thanks!
Ara

> In message <004201c4f889$b1b825a0$1000000a@araav> you wrote:
>>
>> have i complained in my posts? although there is one: that the ixp port 
>> does
>> not support pci support at all though you said "Just do it" to my
>
> You sounded a bit aggressive to me, and you are wrong again: The  IXP
> port does support PCI:
>
>
>
>> > I have a PCI Ethernet card on the board. I need to connect to the 
>> > network
>> > from u-boot via this device.
>>
>> btw, if you don't know the answer to questions, just don't answer:) there
>> are many other users in the list ;)
>
> Here you go again. You should not insult people who you ask for help.
> I know EXACTLY what I'm speaking of. See here:
>
> ---------------------
> PatchSet 1138
> Date: 2005/01/09 17:12:27
> Author: wdenk
> Branch: HEAD
> Tag: (none)
> Log:
> * Patch by Jon Loeliger, 02 Sep 2004:
>   Reset monitor size back to 256 so environment can be written
>   to flash on MPC85xx ADS and CDS releases.
>
> * Patch by Paolo Broggini, 02 Sep 2004:
>   Make BSS clearing on ARM systems more robust
>
> * Patch by Yue Hu and Joe, 01 Sep 2004:
> ===>>>   - add PCI support for ixp425;
> ===>>>   - add EEPRO100 suppor tfor ixdp425 board.
>
> * Fix problem with protected sector detection in driver/cfi_flash.c
>
> Members:
> CHANGELOG:1.406->1.407
> board/ixdp425/ixdp425.c:1.3->1.4
> board/xilinx/xilinx_iic/iic_adapter.c:1.2->1.3
> cpu/arm720t/start.S:1.9->1.10
> cpu/arm920t/start.S:1.9->1.10
> cpu/arm925t/start.S:1.7->1.8
> cpu/arm926ejs/start.S:1.8->1.9
> cpu/at91rm9200/start.S:1.7->1.8
> cpu/ixp/Makefile:1.1->1.2
> cpu/ixp/cpu.c:1.2->1.3
> cpu/ixp/pci.c:INITIAL->1.1
> cpu/ixp/start.S:1.4->1.5
> cpu/lh7a40x/start.S:1.1->1.2
> cpu/pxa/start.S:1.6->1.7
> cpu/sa1100/start.S:1.6->1.7
> drivers/cfi_flash.c:1.15->1.16
> drivers/pci.c:1.10->1.11
> include/version.h:1.25->1.26
> include/asm-arm/arch-ixp/ixp425pci.h:INITIAL->1.1
> include/configs/MPC8540ADS.h:1.6->1.7
> include/configs/MPC8541CDS.h:1.3->1.4
> include/configs/MPC8555CDS.h:1.3->1.4
> include/configs/MPC8560ADS.h:1.6->1.7
> include/configs/ixdp425.h:1.3->1.4
> lib_arm/board.c:1.30->1.31
> ---------------------
>
> Seems it's you who has no clue.
>
> I don't blame you for that - I cannot expect that you spend  so  much
> time with U-Boot like me, but then you should rather think twice what
> you write.
>
> I cannot help you if you continue to ignore what I'm trying  to  tell
> you.
>
>
> Best regards,
>
> Wolfgang Denk
>
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> They say a little knowledge is a dangerous thing,  but it is not  one
> half so bad as a lot of ignorance.   - Terry Pratchett, _Equal Rites_
> 

Linking two recipes

[simran singh]

[-- Attachment #1.1: Type: text/plain, Size: 348 bytes --]


Hello,I have recipes for two applications Recipe A and Recipe B. Recipe B requires a lib.so file and init.h file which are installed by Recipe A.How do I acknowledge this dependency in Recipe B. I tried doing do_stage() function in recipe A with no success. Please advice.I am attaching the two recipes.Thank you for any help.
Simran 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 632 bytes --]

[-- Attachment #2: recipeA.bb --]
[-- Type: application/octet-stream, Size: 1075 bytes --]

DESCRIPTION = "Botan library"
PR = "r0"
SRC_URI = "file://${PN}-${PV}.tar.gz"

export LDFLAGS = "-L${STAGING_LIBDIR}"

S = "${WORKDIR}"

#EXTRA_OEMAKE = 'LINUX=${STAGING_KERNEL_DIR} EXLDFLAGS="${LDFLAGS}" \
#		MACHINE=${TARGET_ARCH} CC="${CC}" AR="${AR}" PREFIX="${prefix}"'

do_configure() {

	mkdir -p ${D}/usr/botan
	cd Botan-1.10.1

#	export PATH=${WORKDIR}:${PATH}
#	export CC=gcc
#	export CXX=g++

	python configure.py --prefix=${D}/usr/botan
#	make
#	make install

}

#TARGET_CC_ARCH += "${LDFLAGS}"

do_compile() {

#	export PATH=${WORKDIR}:${PATH}
#	export CC=gcc
#	export CXX=g++

	cd Botan-1.10.1
	make
	
}

fakeroot do_install() {

	cd Botan-1.10.1
	make install
	cp -r ${WORKDIR}/Botan-1.10.1/* ${D}/usr/botan

}

do_stage() {
#	install -m 0755 ${D}/usr/botan/libbotan-1.10.so.0.1 ${STAGING_LIBDIR}/botan
	install -d ${STAGING_INCDIR}/
	install -d ${STAGING_LIBDIR}
#	cd ${D}/usr/botan
	oe_libinstall -so libbotan-1.10.so.0.1 ${STAGING_LIBDIR}

}

#FILES_${PN} += "${datadir}/botan"
FILES_${PN} += "/usr/bin/botan"
#FILES_${PN} = "${base_libdir}/libgcc*.so.*"



[-- Attachment #3: recipeB.bb --]
[-- Type: application/octet-stream, Size: 624 bytes --]

DESCRIPTION = "SoftHSM"
PR = "r0"
SRC_URI = "file://${PN}-${PV}.tar.gz"

S = "${WORKDIR}"

DEPENDS = "botan sqlite3"
#RDEPENDS = "botan"

export LDFLAGS = "-L${STAGING_LIBDIR}"
export STAGING_LIBDIR

do_configure() {

	mkdir -p ${D}/usr/softhsm

	./softhsm-1.3.1/configure --host --prefix=${D}/usr/softhsm --with-loglevel=4 #--with-botan=${STAGING_LIBDIR}/botan

}

do_compile() {

	make
	
}

fakeroot do_install() {

	make install

}


FILES_${PN} += "/usr/bin/softhsm"
#FILES_${PN} += "/home/Simran/Freescale/QorIQ-DPAA-SDK-20111026-systembuilder/build_p4080ds_release/work/ppce500mc-linux/botan-1.0-r0/image/usr/botan"

Re: Linking two recipes

[Richard Purdie]

On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> Hello,
> I have recipes for two applications Recipe A and Recipe B. Recipe B
> requires a lib.so file and init.h file which are installed by Recipe
> A.
> How do I acknowledge this dependency in Recipe B. I tried doing
> do_stage() function in recipe A with no success. Please advice.
> I am attaching the two recipes.
> Thank you for any help.

recipe B needs to do:

DEPENDS += "recipeA"

Cheers,

Richard

Re: Linking two recipes

[simran singh]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]



Hello Richard,
I did try the DEPENDS variable before but still doesnt solve the problem.A configure script in recipe B has to run a program that is built under ${D}/usr/botan by recipe A. Even if i pass the path to the configure script, it is unable to find the script. ./configure --with-botan=............./usr/botanThanks.
Simran

> From: richard.purdie@linuxfoundation.org
> To: openembedded-core@lists.openembedded.org
> Date: Mon, 19 Mar 2012 21:22:30 +0000
> Subject: Re: [OE-core] Linking two recipes
> 
> On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > Hello,
> > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > requires a lib.so file and init.h file which are installed by Recipe
> > A.
> > How do I acknowledge this dependency in Recipe B. I tried doing
> > do_stage() function in recipe A with no success. Please advice.
> > I am attaching the two recipes.
> > Thank you for any help.
> 
> recipe B needs to do:
> 
> DEPENDS += "recipeA"
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1803 bytes --]

Re: Linking two recipes

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

/usr/botan isn't a path that'll be placed into the sysroot, which is the standard mechanism by which files from dependencies are accessed (e.g. headers, shared libraries, native scripts). You should install to more standard system locations.

-- 
Christopher Larson


On Monday, March 19, 2012 at 2:33 PM, simran singh wrote:

> Hello Richard,
> 
> I did try the DEPENDS variable before but still doesnt solve the problem.
> A configure script in recipe B has to run a program that is built under ${D}/usr/botan by recipe A. 
> Even if i pass the path to the configure script, it is unable to find the script. ./configure --with-botan=............./usr/botan
> Thanks.
> 
> Simran
> 
> 
> > From: richard.purdie@linuxfoundation.org (mailto:richard.purdie@linuxfoundation.org)
> > To: openembedded-core@lists.openembedded.org (mailto:openembedded-core@lists.openembedded.org)
> > Date: Mon, 19 Mar 2012 21:22:30 +0000
> > Subject: Re: [OE-core] Linking two recipes
> > 
> > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > Hello,
> > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > requires a lib.so file and init.h file which are installed by Recipe
> > > A.
> > > How do I acknowledge this dependency in Recipe B. I tried doing
> > > do_stage() function in recipe A with no success. Please advice.
> > > I am attaching the two recipes.
> > > Thank you for any help.
> > 
> > recipe B needs to do:
> > 
> > DEPENDS += "recipeA"
> > 
> > Cheers,
> > 
> > Richard
> > 
> > 
> > 
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org (mailto:Openembedded-core@lists.openembedded.org)
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org (mailto:Openembedded-core@lists.openembedded.org)
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 



[-- Attachment #2: Type: text/html, Size: 3170 bytes --]

Re: Linking two recipes

[simran singh]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]


So install something along the lines:
do_install(){       python configure.py --prefix=${libdir}/botan}

When I do that, I get a permission denied error:mkdir: cannot create directory /usr/lib/botan
Sorry I am still significantly new to open embedded and bitbake.
Thanks,Simran

Date: Mon, 19 Mar 2012 14:39:13 -0700
From: kergoth@gmail.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] Linking two recipes


                /usr/botan isn't a path that'll be placed into the sysroot, which is the standard mechanism by which files from dependencies are accessed (e.g. headers, shared libraries, native scripts). You should install to more standard system locations.

                
-- Christopher Larson

                 
                On Monday, March 19, 2012 at 2:33 PM, simran singh wrote:
                
                    




Hello Richard,
I did try the DEPENDS variable before but still doesnt solve the problem.A configure script in recipe B has to run a program that is built under ${D}/usr/botan by recipe A. Even if i pass the path to the configure script, it is unable to find the script. ./configure --with-botan=............./usr/botanThanks.
Simran

> From: richard.purdie@linuxfoundation.org
> To: openembedded-core@lists.openembedded.org
> Date: Mon, 19 Mar 2012 21:22:30 +0000
> Subject: Re: [OE-core] Linking two recipes
> 
> On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > Hello,
> > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > requires a lib.so file and init.h file which are installed by Recipe
> > A.
> > How do I acknowledge this dependency in Recipe B. I tried doing
> > do_stage() function in recipe A with no success. Please advice.
> > I am attaching the two recipes.
> > Thank you for any help.
> 
> recipe B needs to do:
> 
> DEPENDS += "recipeA"
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 		 	   		  
_______________________________________________Openembedded-core mailing listOpenembedded-core@lists.openembedded.orghttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
                 
                 
                 
                 
                
                 
                
                    

                
            
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core 		 	   		  

[-- Attachment #2: Type: text/html, Size: 4283 bytes --]

Re: Linking two recipes

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]

All installs should be placed relative to ${D}. See one of the many other recipes that define do_install for examples :)

-- 
Christopher Larson


On Monday, March 19, 2012 at 2:57 PM, simran singh wrote:

> So install something along the lines:
> 
> do_install(){
>        python configure.py --prefix=${libdir}/botan
> }
> 
> When I do that, I get a permission denied error:
> mkdir: cannot create directory /usr/lib/botan
> 
> Sorry I am still significantly new to open embedded and bitbake.
> 
> Thanks,
> Simran
> 
> Date: Mon, 19 Mar 2012 14:39:13 -0700
> From: kergoth@gmail.com (mailto:kergoth@gmail.com)
> To: openembedded-core@lists.openembedded.org (mailto:openembedded-core@lists.openembedded.org)
> Subject: Re: [OE-core] Linking two recipes
> 
> /usr/botan isn't a path that'll be placed into the sysroot, which is the standard mechanism by which files from dependencies are accessed (e.g. headers, shared libraries, native scripts). You should install to more standard system locations.
> 
> -- 
> Christopher Larson
> 
> 
> On Monday, March 19, 2012 at 2:33 PM, simran singh wrote:
> 
> > Hello Richard,
> > 
> > I did try the DEPENDS variable before but still doesnt solve the problem.
> > A configure script in recipe B has to run a program that is built under ${D}/usr/botan by recipe A. 
> > Even if i pass the path to the configure script, it is unable to find the script. ./configure --with-botan=............./usr/botan
> > Thanks.
> > 
> > Simran
> > 
> > 
> > > From: richard.purdie@linuxfoundation.org (mailto:richard.purdie@linuxfoundation.org)
> > > To: openembedded-core@lists.openembedded.org (mailto:openembedded-core@lists.openembedded.org)
> > > Date: Mon, 19 Mar 2012 21:22:30 +0000
> > > Subject: Re: [OE-core] Linking two recipes
> > > 
> > > On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > > > Hello,
> > > > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > > > requires a lib.so file and init.h file which are installed by Recipe
> > > > A.
> > > > How do I acknowledge this dependency in Recipe B. I tried doing
> > > > do_stage() function in recipe A with no success. Please advice.
> > > > I am attaching the two recipes.
> > > > Thank you for any help.
> > > 
> > > recipe B needs to do:
> > > 
> > > DEPENDS += "recipeA"
> > > 
> > > Cheers,
> > > 
> > > Richard
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org (mailto:Openembedded-core@lists.openembedded.org)
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org (mailto:Openembedded-core@lists.openembedded.org)
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org (mailto:Openembedded-core@lists.openembedded.org)
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 



[-- Attachment #2: Type: text/html, Size: 5325 bytes --]

Re: Linking two recipes

[simran singh]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]


This is how I was able to install it:
do_install(){       python configure.py --prefix=${D}/${libdir}/botan}
But still the other recipe is unable to locate the files.

Date: Mon, 19 Mar 2012 14:59:33 -0700
From: kergoth@gmail.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] Linking two recipes


                All installs should be placed relative to ${D}. See one of the many other recipes that define do_install for examples :)

                
-- Christopher Larson

                 
                On Monday, March 19, 2012 at 2:57 PM, simran singh wrote:
                
                    



So install something along the lines:
do_install(){       python configure.py --prefix=${libdir}/botan}

When I do that, I get a permission denied error:mkdir: cannot create directory /usr/lib/botan
Sorry I am still significantly new to open embedded and bitbake.
Thanks,Simran

Date: Mon, 19 Mar 2012 14:39:13 -0700
From: kergoth@gmail.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] Linking two recipes


                /usr/botan isn't a path that'll be placed into the sysroot, which is the standard mechanism by which files from dependencies are accessed (e.g. headers, shared libraries, native scripts). You should install to more standard system locations.

                
-- Christopher Larson

                  
                On Monday, March 19, 2012 at 2:33 PM, simran singh wrote:
                    




Hello Richard,
I did try the DEPENDS variable before but still doesnt solve the problem.A configure script in recipe B has to run a program that is built under ${D}/usr/botan by recipe A. Even if i pass the path to the configure script, it is unable to find the script. ./configure --with-botan=............./usr/botanThanks.
Simran

> From: richard.purdie@linuxfoundation.org
> To: openembedded-core@lists.openembedded.org
> Date: Mon, 19 Mar 2012 21:22:30 +0000
> Subject: Re: [OE-core] Linking two recipes
> 
> On Mon, 2012-03-19 at 13:59 -0700, simran singh wrote:
> > Hello,
> > I have recipes for two applications Recipe A and Recipe B. Recipe B
> > requires a lib.so file and init.h file which are installed by Recipe
> > A.
> > How do I acknowledge this dependency in Recipe B. I tried doing
> > do_stage() function in recipe A with no success. Please advice.
> > I am attaching the two recipes.
> > Thank you for any help.
> 
> recipe B needs to do:
> 
> DEPENDS += "recipeA"
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 		 	   		  
_______________________________________________Openembedded-core mailing listOpenembedded-core@lists.openembedded.orghttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
                  
                  
                  
                  
                
                    

                
            
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core 		 	   		  
_______________________________________________Openembedded-core mailing listOpenembedded-core@lists.openembedded.orghttp://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
                 
                 
                 
                 
                
                 
                
                    

                
            
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core 		 	   		  

[-- Attachment #2: Type: text/html, Size: 6311 bytes --]

Re: Linking two recipes

[Richard Purdie]

On Mon, 2012-03-19 at 15:10 -0700, simran singh wrote:
> This is how I was able to install it:
> 
> 
> do_install(){
>        python configure.py --prefix=${D}/${libdir}/botan
> }
>
> 
> But still the other recipe is unable to locate the files.
> 

In the other recipe, look in ${STAGING_LIBDIR}...

Cheers,

Richard

Re: Linking two recipes

[simran singh]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]


Hello,
I was able to have the recipes find each other but I think the problem lies somewhere else as to why the build is failing.But thanks for all the help.
Simran

> From: richard.purdie@linuxfoundation.org
> To: openembedded-core@lists.openembedded.org
> Date: Mon, 19 Mar 2012 22:54:14 +0000
> Subject: Re: [OE-core] Linking two recipes
> 
> On Mon, 2012-03-19 at 15:10 -0700, simran singh wrote:
> > This is how I was able to install it:
> > 
> > 
> > do_install(){
> >        python configure.py --prefix=${D}/${libdir}/botan
> > }
> >
> > 
> > But still the other recipe is unable to locate the files.
> > 
> 
> In the other recipe, look in ${STAGING_LIBDIR}...
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

Re: Linking two recipes

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/2012 12:25 PM, simran singh wrote:
> 
> Hello, I was able to have the recipes find each other but I think 
> the problem lies somewhere else as to why the build is failing.But
>  thanks for all the help. Simran

It seems recipeB needs to run some binary from recipeA during its
configure step which tells me that you need a native version of recipeA
so add BBCLASSEXTEND = "native" to recipeA and then in recipeB add
recipeA-native to DEPENDS

- -Khem

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9/uCYACgkQuwUzVZGdMxR+sgCdEx+b67XQhyH0V9cE6PtRKVk0
JRsAn0x5DBv9wILS1RGl8vw347lUz1uN
=8c5R
-----END PGP SIGNATURE-----

lots of connections in SYN_RECV state

[Puneet Agarwal]

Hello,

I have a couple of servers, for the past few days I am seeing lots of connections in SYN_RECV state in netstat commands output.
Is there a solution to this problem?

Thanks and Regards
Puneet 		 	   		  

lots of connections in SYN_RECV state

[Silvan Jegen]

Hi

Am 2014-11-06 14:27, schrieb Puneet Agarwal:
> I have a couple of servers, for the past few days I am seeing lots of
> connections in SYN_RECV state in netstat commands output.

This *could* be the result of a SYN-flood attack on your server.


> Is there a solution to this problem?

The Wikipedia page mentions some countermeasures (if it indeed is an 
attack and not a networking stack issue).

http://en.wikipedia.org/wiki/SYN_flood

Maybe you could check from which IP addresses these SYNs come from and 
investigate why they do not answer to the SYN-ACK request of your 
server.


Cheers,

Silvan

lots of connections in SYN_RECV state

[Puneet Agarwal]

nslookup does not give any result on those IP addresses.
So not able to figure out who is causing this.

Is there a way to check the reason, why?they do not answer to the SYN-ACK's?

Thanks and Regards
Puneet

----------------------------------------
> Date: Thu, 6 Nov 2014 15:30:46 +0100
> From: me at sillymon.ch
> To: puneet.agr at outlook.com
> CC: kernelnewbies at kernelnewbies.org
> Subject: Re: lots of connections in SYN_RECV state
>
> Hi
>
> Am 2014-11-06 14:27, schrieb Puneet Agarwal:
>> I have a couple of servers, for the past few days I am seeing lots of
>> connections in SYN_RECV state in netstat commands output.
>
> This *could* be the result of a SYN-flood attack on your server.
>
>
>> Is there a solution to this problem?
>
> The Wikipedia page mentions some countermeasures (if it indeed is an
> attack and not a networking stack issue).
>
> http://en.wikipedia.org/wiki/SYN_flood
>
> Maybe you could check from which IP addresses these SYNs come from and
> investigate why they do not answer to the SYN-ACK request of your
> server.
>
>
> Cheers,
>
> Silvan
 		 	   		  

lots of connections in SYN_RECV state

[Silvan Jegen]

2014-11-06 16:15,Puneet Agarwal:
> Is there a way to check the reason, why?they do not answer to the 
> SYN-ACK's?

I don't think so. After all, they just don't answer and they won't tell 
you why (AFAIK there is no way to ask them why either)...

You could try to check for patterns in the incoming IP addresses to see 
from how many different places these connections are being made. I think 
that way it should be possible to figure out from which geographic 
location these problematic connections are coming from as well. What you 
would do with these findings I am not sure though.

If these connection negatively impact the performance of your servers 
you should definitely look into to countermeasures mentioned in the RFC 
here.

http://tools.ietf.org/html/rfc4987

lots of connections in SYN_RECV state

[Dave Tian]

Latest kernel provides a TCP SYN Cookie feature to defense from SYN flooding.

-daveti


> On Nov 6, 2014, at 11:58 PM, Silvan Jegen <me@sillymon.ch> wrote:
> 
> 2014-11-06 16:15,Puneet Agarwal:
>> Is there a way to check the reason, why they do not answer to the 
>> SYN-ACK's?
> 
> I don't think so. After all, they just don't answer and they won't tell 
> you why (AFAIK there is no way to ask them why either)...
> 
> You could try to check for patterns in the incoming IP addresses to see 
> from how many different places these connections are being made. I think 
> that way it should be possible to figure out from which geographic 
> location these problematic connections are coming from as well. What you 
> would do with these findings I am not sure though.
> 
> If these connection negatively impact the performance of your servers 
> you should definitely look into to countermeasures mentioned in the RFC 
> here.
> 
> http://tools.ietf.org/html/rfc4987
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

lots of connections in SYN_RECV state

[Valdis.Kletnieks at vt.edu]

On Fri, 07 Nov 2014 23:49:35 +0800, Dave Tian said:
> Latest kernel provides a TCP SYN Cookie feature to defense from SYN flooding.

If by "latest" you mean "since Andi Kleen submitted a patch for 2.1.44",
back in July 1997....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141107/04ef8f13/attachment.bin 

lots of connections in SYN_RECV state

[Puneet Agarwal]

I use linux kernel 2.6. I have enabled SYN cookies already. But that does not seem to solve the problem. Overall request latency is very high with these many half open connections.

Thanks and Regards
Puneet
----------------------------------------
> Subject: Re: lots of connections in SYN_RECV state
> From: dave.jing.tian at gmail.com
> Date: Fri, 7 Nov 2014 23:49:35 +0800
> CC: puneet.agr at outlook.com; kernelnewbies at kernelnewbies.org
> To: me at sillymon.ch
>
> Latest kernel provides a TCP SYN Cookie feature to defense from SYN flooding.
>
> -daveti
>
>
>> On Nov 6, 2014, at 11:58 PM, Silvan Jegen <me@sillymon.ch> wrote:
>>
>> 2014-11-06 16:15,Puneet Agarwal:
>>> Is there a way to check the reason, why they do not answer to the
>>> SYN-ACK's?
>>
>> I don't think so. After all, they just don't answer and they won't tell
>> you why (AFAIK there is no way to ask them why either)...
>>
>> You could try to check for patterns in the incoming IP addresses to see
>> from how many different places these connections are being made. I think
>> that way it should be possible to figure out from which geographic
>> location these problematic connections are coming from as well. What you
>> would do with these findings I am not sure though.
>>
>> If these connection negatively impact the performance of your servers
>> you should definitely look into to countermeasures mentioned in the RFC
>> here.
>>
>> http://tools.ietf.org/html/rfc4987
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
 		 	   		  

lots of connections in SYN_RECV state

[Valdis.Kletnieks at vt.edu]

On Fri, 07 Nov 2014 23:11:26 +0530, Puneet Agarwal said:

> I use linux kernel 2.6. I have enabled SYN cookies already. But that does not
> seem to solve the problem. Overall request latency is very high with these many
> half open connections.

So, out of curiosity, where are all these half open connections coming
from?  Are they from addresses in your local network?  Outside sites that
*should* be connecting?  Places you've never heard and and probably *shouldn't*
be connecting?

(Also, if you have properly implemented syncookies, you shouldn't *have* any
half-open connections.  That's the whole point of syncookies....)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141107/85f1f4aa/attachment.bin 

lots of connections in SYN_RECV state

[Dave Tian]

Oops, my bad. I remember seeing sth on LWN for the 3.x kernel talking about a new feature related with TCP SYN. Thought this pretty old stuff was the one?

-daveti


> On Nov 8, 2014, at 12:58 AM, Valdis.Kletnieks at vt.edu wrote:
> 
> On Fri, 07 Nov 2014 23:49:35 +0800, Dave Tian said:
>> Latest kernel provides a TCP SYN Cookie feature to defense from SYN flooding.
> 
> If by "latest" you mean "since Andi Kleen submitted a patch for 2.1.44",
> back in July 1997....

lots of connections in SYN_RECV state

[Puneet Agarwal]

These connections are from outside the network, and the IP's are legitimate ones which should be connecting.
I don't know whether the IP's which I could see are the real ones or spoofed ones.

sysctl -a says
net.ipv4.tcp_syncookies = 1

cat /proc/sys/net/ipv4/tcp_syncookies also gives 1

Isn't this sufficient to enable syncookies?

Thanks and Regards
Puneet
----------------------------------------
> To: puneet.agr at outlook.com
> CC: dave.jing.tian at gmail.com; me at sillymon.ch; kernelnewbies at kernelnewbies.org
> Subject: Re: lots of connections in SYN_RECV state
> From: Valdis.Kletnieks at vt.edu
> Date: Fri, 7 Nov 2014 13:10:05 -0500
>
> On Fri, 07 Nov 2014 23:11:26 +0530, Puneet Agarwal said:
>
>> I use linux kernel 2.6. I have enabled SYN cookies already. But that does not
>> seem to solve the problem. Overall request latency is very high with these many
>> half open connections.
>
> So, out of curiosity, where are all these half open connections coming
> from? Are they from addresses in your local network? Outside sites that
> *should* be connecting? Places you've never heard and and probably *shouldn't*
> be connecting?
>
> (Also, if you have properly implemented syncookies, you shouldn't *have* any
> half-open connections. That's the whole point of syncookies....)
>
 		 	   		  

UBIFS: Is it possible to get the compressed size of a file?

[markus.heininger]

Hello,
 
when using compression along with UBIfs, fstat reports the uncompressed file size
(as it should do). Is there a simple way to get the compressed file size, thus the real space
a single file needs on the flash memory?
 
Many thanks,
Markus

Re: UBIFS: Is it possible to get the compressed size of a file?

[hujianyang]

On 2014/12/12 16:10, markus.heininger@online.de wrote:
> Hello,
>  
> when using compression along with UBIfs, fstat reports the uncompressed file size
> (as it should do). Is there a simple way to get the compressed file size, thus the real space
> a single file needs on the flash memory?

Why you need this?

I know *df* shows the space of a partition. Run *sync* after
a file created or appended, the space change of this partition
maybe could show you the compressed size of this file.

Is that enough for you?

>  
> Many thanks,
> Markus
> 

Aw: Re: UBIFS: Is it possible to get the compressed size of a file?

[markus.heininger]

Hello,

in our system we´re using ring buffers where it is necessary to
remove old files from certain directories when the physical usage
of each directory is above a certain level which is different for each 
folder.

Evaluating the output of "df" after write access might be difficult
since there are several concurrent writing processes.

But many thanks for your answer, it seems that there is no easy
way to get the information needed and we must investigate further on
our own.

With best regards,
Markus

Gesendet: Mittwoch, 17. Dezember 2014 um 07:22 Uhr
Von: hujianyang <hujianyang@huawei.com>
An: "markus.heininger@online.de" <markus.heininger@online.de>
Cc: linux-mtd@lists.infradead.org, "Artem Bityutskiy" <dedekind1@gmail.com>
Betreff: Re: UBIFS: Is it possible to get the compressed size of a file?
On 2014/12/12 16:10, markus.heininger@online.de wrote:
> Hello,
>
> when using compression along with UBIfs, fstat reports the uncompressed file size
> (as it should do). Is there a simple way to get the compressed file size, thus the real space
> a single file needs on the flash memory?

Why you need this?

I know *df* shows the space of a partition. Run *sync* after
a file created or appended, the space change of this partition
maybe could show you the compressed size of this file.

Is that enough for you?

>
> Many thanks,
> Markus
>

 

Yocto-custom kernel build issue

[Raghavendra Kakarla]

Hi,

I am new to yocto project build system. I downloaded the yocto project build system from git. I built for the all qemu architectures(MIPS,ARM,PPC,X86) and ran on qemu.

all are working fine.

Now I need to create a bsp layer for my board which has the mips processor core.

I created the bsp layer with using the yocto-bsp create command.

here I use the my own kernel which is reside at our local git repositery. I gave this path while creating the bsplayer.

After adding my bsp layer to bblayers and my mechine to local.conf i built the kernel using bitbake -k core-image-minimal command.

While building i got the following errors:


Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| NOTE: make oldnoconfig
| make: *** No rule to make target `oldnoconfig'.  Stop.
| NOTE: make oldconfig
| make: *** No rule to make target `oldconfig'.  Stop.
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+12bbf6468e-r0/temp/log.do_configure.14044)

And also i did not got "src" folder in the following path for my mechine which is there for the qemu mips.
/home/testuser/poky/build/tmp/sysroots/mydhanush/usr

could you please help for resolving this issue.

thanks in advance.


 

Thanks & Regards,
Raghavendra K.

Re: Yocto-custom kernel build issue

[Bruce Ashfield]

On 15-01-30 09:08 AM, Raghavendra Kakarla wrote:
> Hi,
>
> I am new to yocto project build system. I downloaded the yocto project build system from git. I built for the all qemu architectures(MIPS,ARM,PPC,X86) and ran on qemu.
>
> all are working fine.
>
> Now I need to create a bsp layer for my board which has the mips processor core.
>
> I created the bsp layer with using the yocto-bsp create command.
>
> here I use the my own kernel which is reside at our local git repositery. I gave this path while creating the bsplayer.
>
> After adding my bsp layer to bblayers and my mechine to local.conf i built the kernel using bitbake -k core-image-minimal command.
>
> While building i got the following errors:
>
>
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: Executing shell function do_configure
> | NOTE: make oldnoconfig
> | make: *** No rule to make target `oldnoconfig'.  Stop.
> | NOTE: make oldconfig
> | make: *** No rule to make target `oldconfig'.  Stop.
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+12bbf6468e-r0/temp/log.do_configure.14044)
>
> And also i did not got "src" folder in the following path for my mechine which is there for the qemu mips.
> /home/testuser/poky/build/tmp/sysroots/mydhanush/usr

Is the source directory in 
/home/testuser/poky/build/tmp/work-shared/<your machine>/kernel-source ?

And if so, is your recipe setting ${S} in any way ?

Bruce

>
> could you please help for resolving this issue.
>
> thanks in advance.
>
>
>
>
> Thanks & Regards,
> Raghavendra K.
>

Re: UBIFS: Is it possible to get the compressed size of a file?

[Artem Bityutskiy]

Hi Markus,

On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote:
> in our system we´re using ring buffers where it is necessary to
> remove old files from certain directories when the physical usage
> of each directory is above a certain level which is different for each 
> folder.
> 
> Evaluating the output of "df" after write access might be difficult
> since there are several concurrent writing processes.
> 
> But many thanks for your answer, it seems that there is no easy
> way to get the information needed and we must investigate further on
> our own.

Yes, no easy way, but I think implementing what you need is possible. I
do not have plans and time to work on this, but I can help by giving
advises and review.

The question has 2 major parts.

1. The interface
2. The implementation


For the former, one need to carefully investigate if there is something
like this already implemented for other file-systems. I think btrfs may
have it. If it is, then UBIFS should use similar interface, probably.

And whatever is the interface choice, it should be discussed in the
linux-fsdevel@vger.kernel.org mailing list, which I am CCing.


For the latter, I'd suggest to try this.

a. 'struct ubifs_ino_node' has unused space, use it to add the
compressed size field.
b. maintain this field
c. this field will only be correct for the part of the file which are on
the media. The dirty data in the page cache has not yet been compressed,
so we do not know its compressed size yet.
e. when user asks for the compressed size, you have to sync the inode
first, in order to make sure the compressed size is correct.

And the implementation should be backward-compatible. That is, if new
driver mounts the old media, you return something predicatable. I guess
uncompressed size could be it.


Hope this helps,
Artem.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: UBIFS: Is it possible to get the compressed size of a file?

[Artem Bityutskiy]

Hi Markus,

On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote:
> in our system we´re using ring buffers where it is necessary to
> remove old files from certain directories when the physical usage
> of each directory is above a certain level which is different for each 
> folder.
> 
> Evaluating the output of "df" after write access might be difficult
> since there are several concurrent writing processes.
> 
> But many thanks for your answer, it seems that there is no easy
> way to get the information needed and we must investigate further on
> our own.

Yes, no easy way, but I think implementing what you need is possible. I
do not have plans and time to work on this, but I can help by giving
advises and review.

The question has 2 major parts.

1. The interface
2. The implementation


For the former, one need to carefully investigate if there is something
like this already implemented for other file-systems. I think btrfs may
have it. If it is, then UBIFS should use similar interface, probably.

And whatever is the interface choice, it should be discussed in the
linux-fsdevel@vger.kernel.org mailing list, which I am CCing.


For the latter, I'd suggest to try this.

a. 'struct ubifs_ino_node' has unused space, use it to add the
compressed size field.
b. maintain this field
c. this field will only be correct for the part of the file which are on
the media. The dirty data in the page cache has not yet been compressed,
so we do not know its compressed size yet.
e. when user asks for the compressed size, you have to sync the inode
first, in order to make sure the compressed size is correct.

And the implementation should be backward-compatible. That is, if new
driver mounts the old media, you return something predicatable. I guess
uncompressed size could be it.


Hope this helps,
Artem.

Yocto-custom kernel build issue

[Raghavendra Kakarla]

Hi,
I want to add my own BSP layer to yocto and also we use our inhouse customizied kernel.
I add my BSP layer to yocto using yocto-bsp create command. 
I give the our curtomized kernel repositary path to the git path while creating the BSP.

After successfully creating the BSP layer when I run the "bitbake -k core-image-minimal" I got the error as follows.

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| ERROR: S is not set to the linux source directory. Check
| ERROR: the recipe and set S to the proper extracted subdirectory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_checkout (log file is located at /home/testuser/poky/build/tmp/work/dhruwa-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)


could you please help for resolving this issue.

Thanks and Regards,

Raghavendra.

Re: UBIFS: Is it possible to get the compressed size of a file?

[Andreas Dilger]

On Feb 2, 2015, at 2:33 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Hi Markus,
> 
> On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote:
>> in our system we´re using ring buffers where it is necessary to
>> remove old files from certain directories when the physical usage
>> of each directory is above a certain level which is different for each 
>> folder.
>> 
>> Evaluating the output of "df" after write access might be difficult
>> since there are several concurrent writing processes.
>> 
>> But many thanks for your answer, it seems that there is no easy
>> way to get the information needed and we must investigate further on
>> our own.
> 
> Yes, no easy way, but I think implementing what you need is possible. I
> do not have plans and time to work on this, but I can help by giving
> advises and review.
> 
> The question has 2 major parts.
> 
> 1. The interface
> 2. The implementation
> 
> For the former, one need to carefully investigate if there is something
> like this already implemented for other file-systems. I think btrfs may
> have it. If it is, then UBIFS should use similar interface, probably.
> 
> And whatever is the interface choice, it should be discussed in the
> linux-fsdevel@vger.kernel.org mailing list, which I am CCing.

One option that was discussed for btrfs was to use the first fe_reserved
field for the FIEMAP ioctl struct fiemap_extent to fe_phys_length to
hold the compressed size of each extent in the file.

http://lwn.net/Articles/607552/
http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312

I'm not sure what happened to that patch series - I was looking forward
to it landing, and it was in very good shape I think.

I think FIEMAP would be a good userspace API to get this kind of
low-level allocation information about the compressed size of data.
For most files it would probably only need a single fiemap_extent
to return the allocation data.

Cheers, Andreas

> For the latter, I'd suggest to try this.
> 
> a. 'struct ubifs_ino_node' has unused space, use it to add the
> compressed size field.
> b. maintain this field
> c. this field will only be correct for the part of the file which are on
> the media. The dirty data in the page cache has not yet been compressed,
> so we do not know its compressed size yet.
> e. when user asks for the compressed size, you have to sync the inode
> first, in order to make sure the compressed size is correct.
> 
> And the implementation should be backward-compatible. That is, if new
> driver mounts the old media, you return something predicatable. I guess
> uncompressed size could be it.
> 
> 
> Hope this helps,
> Artem.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: UBIFS: Is it possible to get the compressed size of a file?

[Andreas Dilger]

On Feb 2, 2015, at 2:33 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> Hi Markus,
> 
> On Thu, 2014-12-18 at 12:08 +0100, markus.heininger@online.de wrote:
>> in our system we´re using ring buffers where it is necessary to
>> remove old files from certain directories when the physical usage
>> of each directory is above a certain level which is different for each 
>> folder.
>> 
>> Evaluating the output of "df" after write access might be difficult
>> since there are several concurrent writing processes.
>> 
>> But many thanks for your answer, it seems that there is no easy
>> way to get the information needed and we must investigate further on
>> our own.
> 
> Yes, no easy way, but I think implementing what you need is possible. I
> do not have plans and time to work on this, but I can help by giving
> advises and review.
> 
> The question has 2 major parts.
> 
> 1. The interface
> 2. The implementation
> 
> For the former, one need to carefully investigate if there is something
> like this already implemented for other file-systems. I think btrfs may
> have it. If it is, then UBIFS should use similar interface, probably.
> 
> And whatever is the interface choice, it should be discussed in the
> linux-fsdevel@vger.kernel.org mailing list, which I am CCing.

One option that was discussed for btrfs was to use the first fe_reserved
field for the FIEMAP ioctl struct fiemap_extent to fe_phys_length to
hold the compressed size of each extent in the file.

http://lwn.net/Articles/607552/
http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312

I'm not sure what happened to that patch series - I was looking forward
to it landing, and it was in very good shape I think.

I think FIEMAP would be a good userspace API to get this kind of
low-level allocation information about the compressed size of data.
For most files it would probably only need a single fiemap_extent
to return the allocation data.

Cheers, Andreas

> For the latter, I'd suggest to try this.
> 
> a. 'struct ubifs_ino_node' has unused space, use it to add the
> compressed size field.
> b. maintain this field
> c. this field will only be correct for the part of the file which are on
> the media. The dirty data in the page cache has not yet been compressed,
> so we do not know its compressed size yet.
> e. when user asks for the compressed size, you have to sync the inode
> first, in order to make sure the compressed size is correct.
> 
> And the implementation should be backward-compatible. That is, if new
> driver mounts the old media, you return something predicatable. I guess
> uncompressed size could be it.
> 
> 
> Hope this helps,
> Artem.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas

Re: UBIFS: Is it possible to get the compressed size of a file?

[Artem Bityutskiy]

On Mon, 2015-02-02 at 22:45 -0700, Andreas Dilger wrote:
> I think FIEMAP would be a good userspace API to get this kind of
> low-level allocation information about the compressed size of data.
> For most files it would probably only need a single fiemap_extent
> to return the allocation data.

Thanks Andreas,

indeed FIEMAP sounds like a good answer to the problem.

Artem.

Re: UBIFS: Is it possible to get the compressed size of a file?

[Artem Bityutskiy]

On Mon, 2015-02-02 at 22:45 -0700, Andreas Dilger wrote:
> I think FIEMAP would be a good userspace API to get this kind of
> low-level allocation information about the compressed size of data.
> For most files it would probably only need a single fiemap_extent
> to return the allocation data.

Thanks Andreas,

indeed FIEMAP sounds like a good answer to the problem.

Artem.

yocto-custom-kernel issue

[Raghavendra Kakarla]

Hi,
 I want to add BSP layer for my mechine and I should take the our own customized kernel source(our kernel source).

 For that I add the BSP layer and wrote the recipe for that.

 My recipe is as follows:

*******************************************************************************************************************************************************

 # This file was derived from the linux-yocto-custom.bb recipe in
# oe-core.
#
# linux-yocto-custom.bb:
#
#   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
#   oe-core kernel classes to apply a subset of yocto kernel
#   management to git managed kernel repositories.
#
# Warning:
#
#   Building this kernel without providing a defconfig or BSP
#   configuration will result in build or boot errors. This is not a
#   bug.
#
# Notes:
#
#   patches: patches can be merged into to the source git tree itself,
#            added via the SRC_URI, or controlled via a BSP
#            configuration.
#
#   example configuration addition:
#            SRC_URI += "file://smp.cfg"
#   example patch addition:
#            SRC_URI += "file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
#   example feature addition:
#            SRC_URI += "file://feature.scc"
#
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

SRC_URI = "git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"

SRC_URI += "file://defconfig"

SRC_URI += "file://mydhanush.scc \
            file://mydhanush.cfg \
            file://mydhanush-user-config.cfg \
            file://mydhanush-user-patches.scc \
           "


LINUX_VERSION ?= "3.10.14"
LINUX_VERSION_EXTENSION ?= "-custom"

#SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
PR = "r0"
PV = "${LINUX_VERSION}+git${SRCPV}"

#COMPATIBLE_MACHINE_mydhanush = "mydhanush"
COMPATIBLE_MACHINE_mydhanush = "mydhanush"

***************************************************************************************************************************************************************


but I got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| ERROR: S is not set to the linux source directory. Check
| ERROR: the recipe and set S to the proper extracted subdirectory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_checkout (log file is located at /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)

could you please help for resolving this issue.

Thanks and Regards,

Raghavendra.

Re: yocto-custom-kernel issue

[Sven Ebenfeld]

Hi Raghavendra,

Am 03.02.2015 um 13:40 schrieb Raghavendra Kakarla:
> Hi,
>  I want to add BSP layer for my mechine and I should take the our own customized kernel source(our kernel source).
> 
>  For that I add the BSP layer and wrote the recipe for that.
> 
>  My recipe is as follows:
> 
> *******************************************************************************************************************************************************
> 
>  # This file was derived from the linux-yocto-custom.bb recipe in
> # oe-core.
> #
> # linux-yocto-custom.bb:
> #
> #   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
> #   oe-core kernel classes to apply a subset of yocto kernel
> #   management to git managed kernel repositories.
> #
> # Warning:
> #
> #   Building this kernel without providing a defconfig or BSP
> #   configuration will result in build or boot errors. This is not a
> #   bug.
> #
> # Notes:
> #
> #   patches: patches can be merged into to the source git tree itself,
> #            added via the SRC_URI, or controlled via a BSP
> #            configuration.
> #
> #   example configuration addition:
> #            SRC_URI += "file://smp.cfg"
> #   example patch addition:
> #            SRC_URI += "file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
> #   example feature addition:
> #            SRC_URI += "file://feature.scc"
> #
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 
> SRC_URI = "git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"

Why are you doing a bareclone??
Shouldn't it do a checkout to have a working copy that it can compile?

> 
> SRC_URI += "file://defconfig"
> 
> SRC_URI += "file://mydhanush.scc \
>             file://mydhanush.cfg \
>             file://mydhanush-user-config.cfg \
>             file://mydhanush-user-patches.scc \
>            "
> 
> 
> LINUX_VERSION ?= "3.10.14"
> LINUX_VERSION_EXTENSION ?= "-custom"
> 
> #SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
> SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
> PR = "r0"
> PV = "${LINUX_VERSION}+git${SRCPV}"
> 
> #COMPATIBLE_MACHINE_mydhanush = "mydhanush"
> COMPATIBLE_MACHINE_mydhanush = "mydhanush"
> 
> ***************************************************************************************************************************************************************
> 
> 
> but I got error as follows:
> 
> Log data follows:
> | DEBUG: Executing shell function do_kernel_checkout
> | ERROR: S is not set to the linux source directory. Check
> | ERROR: the recipe and set S to the proper extracted subdirectory

This states, that it doesn't find the source directory where it is
expected. If "bareclone=1" has the effect I think it has, this is normal
as there will probably only be a bare git repository insted of it's
working copy.

> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_kernel_checkout (log file is located at /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)
> 
> could you please help for resolving this issue.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 

Cheers,
Sven

Re: yocto-custom-kernel issue

[Bruce Ashfield]

On 15-02-03 07:40 AM, Raghavendra Kakarla wrote:
> Hi,
>   I want to add BSP layer for my mechine and I should take the our own customized kernel source(our kernel source).
>
>   For that I add the BSP layer and wrote the recipe for that.
>
>   My recipe is as follows:
>
> *******************************************************************************************************************************************************
>
>   # This file was derived from the linux-yocto-custom.bb recipe in
> # oe-core.
> #
> # linux-yocto-custom.bb:
> #
> #   A yocto-bsp-generated kernel recipe that uses the linux-yocto and
> #   oe-core kernel classes to apply a subset of yocto kernel
> #   management to git managed kernel repositories.
> #
> # Warning:
> #
> #   Building this kernel without providing a defconfig or BSP
> #   configuration will result in build or boot errors. This is not a
> #   bug.
> #
> # Notes:
> #
> #   patches: patches can be merged into to the source git tree itself,
> #            added via the SRC_URI, or controlled via a BSP
> #            configuration.
> #
> #   example configuration addition:
> #            SRC_URI += "file://smp.cfg"
> #   example patch addition:
> #            SRC_URI += "file://0/home/testuser/yocto.git/android-linux-mti-unif-3.10.14/arch/mips/configs001-linux-version-tweak.patch
> #   example feature addition:
> #            SRC_URI += "file://feature.scc"
> #
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> SRC_URI = "git://192.168.42.75/vineethchowdhary/incdhad1-kernel-3-10.git;protocol=http;bareclone=1"
>
> SRC_URI += "file://defconfig"
>
> SRC_URI += "file://mydhanush.scc \
>              file://mydhanush.cfg \
>              file://mydhanush-user-config.cfg \
>              file://mydhanush-user-patches.scc \
>             "
>
>
> LINUX_VERSION ?= "3.10.14"
> LINUX_VERSION_EXTENSION ?= "-custom"
>
> #SRCREV="12bbf6468e2ef179800aaab46c724f523b5002e3"
> SRCREV="f91e563c45d457aa441f687eda294ad899e2b25f"
> PR = "r0"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> #COMPATIBLE_MACHINE_mydhanush = "mydhanush"
> COMPATIBLE_MACHINE_mydhanush = "mydhanush"
>
> ***************************************************************************************************************************************************************
>
>
> but I got error as follows:
>
> Log data follows:
> | DEBUG: Executing shell function do_kernel_checkout
> | ERROR: S is not set to the linux source directory. Check
> | ERROR: the recipe and set S to the proper extracted subdirectory
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_kernel_checkout (log file is located at /home/testuser/poky/build/tmp/work/mydhanush-poky-linux/linux-yocto-custom/3.10.14+gitAUTOINC+f91e563c45-r0/temp/log.do_kernel_checkout.11798)
>
> could you please help for resolving this issue.

And if dump the bitbake environment for your kernel build, what is S
set to ? And when you go to that same directory on your build machine,
what do you see ?

The checkout code is telling you that it doesn't see a Makefile in
the source directory, so where ever it is pointing isn't valid.

Cheers,

Bruce

>
> Thanks and Regards,
>
> Raghavendra.
>

MIPS32r2 little endian bsp

[Raghavendra Kakarla]

Hi,

I need to create a bsp layer for my board which is having mips32r2 little endian processor.

I gone through the YOCTO BSP user manual bit there is no information for little endian.

When I create with the yoct-bsp command is taking the mips32 big endian only.

Could you please help me in resolving this issue.


Thanks and regards,

Raghavendra.

Re: MIPS32r2 little endian bsp

[Mark Hatle]

On 2/5/15 2:56 AM, Raghavendra Kakarla wrote:
> Hi,
> 
> I need to create a bsp layer for my board which is having mips32r2 little endian processor.
> 
> I gone through the YOCTO BSP user manual bit there is no information for little endian.
> 
> When I create with the yoct-bsp command is taking the mips32 big endian only.
> 
> Could you please help me in resolving this issue.

You will need to define a BSP that is little endian capable.

The BSP should define:

 DEFAULTTUNE ?= "mips32r2el"

You can verify the setting using bitbake -e and inspecting the value of
DEFAULTTUNE.  The BSP should set that value -before- the necessary line:

require conf/machine/include/tune-mips32r2.inc


(Note, Little endian is not nearly as well tested as big endian for mips.  I
expect you will find some bugs, we'll be happy to take back any fixes for those
issues.)

--Mark

> 
> Thanks and regards,
> 
> Raghavendra.
> 

Re: Yocto-custom kernel build issue

[Raghavendra Kakarla]

Hi,

I am built the yocto for my custom machine. After booting a login prompt was came.
For that I tried the "root" as user name but it did not take it.

Could please tell me where i can get the login and password details for yocto rootfs.



Thanks and Regards,

Raghavendra. 

Re: Yocto-custom kernel build issue

[Paul Eggleton]

On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> I am built the yocto for my custom machine. After booting a login prompt was
> came. For that I tried the "root" as user name but it did not take it.
> 
> Could please tell me where i can get the login and password details for
> yocto rootfs.

The default is root with no password. If that doesn't work, do you have 
"debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Yocto-custom kernel build issue

[Paul Eggleton]

Please keep replies on the mailing list, thanks.

Is this perhaps because you extracted the files onto an SD card / other storage 
device as a non-root user?

Cheers,
Paul

On Tuesday 10 February 2015 17:55:25 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Thank you for your response.
> 
> It is the rootfs permissions issue.
> 
> I give the "chown -R root rfs" to my rfs then it is working.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 
> ----- Original Message -----
> From: "Paul Eggleton" <paul.eggleton@linux.intel.com>
> To: "Raghavendra Kakarla" <raghavendra.kakarla@inedasystems.com>
> Cc: yocto@yoctoproject.org
> Sent: Tuesday, February 10, 2015 4:30:19 PM
> Subject: Re: [yocto] Yocto-custom kernel build issue
> 
> On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> > I am built the yocto for my custom machine. After booting a login prompt
> > was came. For that I tried the "root" as user name but it did not take
> > it.
> > 
> > Could please tell me where i can get the login and password details for
> > yocto rootfs.
> 
> The default is root with no password. If that doesn't work, do you have
> "debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.
> 
> Cheers,
> Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Yocto-custom kernel build issue

[Raghavendra Kakarla]

Yes I extracted the files on to the SD card.

I have one issue now.

I want to build some packages from openWRT which are not in YOCTO in yocto build system.

For this I download the package tar files from openwrt wrote the recipe for building this tar files. Building the tar files is completed without any errors but when installing this package in the image it give some error like following.
ERROR: hostapd not found in the base feeds (dhruwa_ioe mips32r2el mips32el mipsel noarch any all). 

Could you plese help in resolving this isssue.

Thanks and Regards,
Raghavendra.

----- Original Message -----
From: "Paul Eggleton" <paul.eggleton@linux.intel.com>
To: "Raghavendra Kakarla" <raghavendra.kakarla@inedasystems.com>, yocto@yoctoproject.org
Sent: Tuesday, February 10, 2015 7:06:37 PM
Subject: Re: [yocto] Yocto-custom kernel build issue

Please keep replies on the mailing list, thanks.

Is this perhaps because you extracted the files onto an SD card / other storage 
device as a non-root user?

Cheers,
Paul

On Tuesday 10 February 2015 17:55:25 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Thank you for your response.
> 
> It is the rootfs permissions issue.
> 
> I give the "chown -R root rfs" to my rfs then it is working.
> 
> Thanks and Regards,
> 
> Raghavendra.
> 
> ----- Original Message -----
> From: "Paul Eggleton" <paul.eggleton@linux.intel.com>
> To: "Raghavendra Kakarla" <raghavendra.kakarla@inedasystems.com>
> Cc: yocto@yoctoproject.org
> Sent: Tuesday, February 10, 2015 4:30:19 PM
> Subject: Re: [yocto] Yocto-custom kernel build issue
> 
> On Tuesday 10 February 2015 13:47:45 Raghavendra Kakarla wrote:
> > I am built the yocto for my custom machine. After booting a login prompt
> > was came. For that I tried the "root" as user name but it did not take
> > it.
> > 
> > Could please tell me where i can get the login and password details for
> > yocto rootfs.
> 
> The default is root with no password. If that doesn't work, do you have
> "debug-tweaks" in your EXTRA_IMAGE_FEATURES? It should be there by default.
> 
> Cheers,
> Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Yocto-custom kernel build issue

[Paul Eggleton]

On Wednesday 11 February 2015 10:25:51 Raghavendra Kakarla wrote:
> Yes I extracted the files on to the SD card.

Right, and the lesson is you must do that as root, not as a normal user.

> I want to build some packages from openWRT which are not in YOCTO in yocto
> build system.
> 
> For this I download the package tar files from openwrt wrote the recipe for
> building this tar files. Building the tar files is completed without any
> errors but when installing this package in the image it give some error
> like following. ERROR: hostapd not found in the base feeds (dhruwa_ioe
> mips32r2el mips32el mipsel noarch any all).

My advice here is to use the recipe we already have in the community to build 
this:

http://layers.openembedded.org/layerindex/branch/master/recipes/?q=hostapd

In general the OE layer index is the best place to find layers providing 
recipes to build anything that isn't already supplied in Poky/OE-core by 
default.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Yocto-custom kernel build issue

[Raghavendra Kakarla]

Thanks Paul,

I will make use of hostapd recipe present in the openembedded layer.

cheers,
Raghavendra.

----- Original Message -----
From: "Paul Eggleton" <paul.eggleton@linux.intel.com>
To: "Raghavendra Kakarla" <raghavendra.kakarla@inedasystems.com>
Cc: yocto@yoctoproject.org
Sent: Wednesday, February 11, 2015 3:00:57 PM
Subject: Re: [yocto] Yocto-custom kernel build issue

On Wednesday 11 February 2015 10:25:51 Raghavendra Kakarla wrote:
> Yes I extracted the files on to the SD card.

Right, and the lesson is you must do that as root, not as a normal user.

> I want to build some packages from openWRT which are not in YOCTO in yocto
> build system.
> 
> For this I download the package tar files from openwrt wrote the recipe for
> building this tar files. Building the tar files is completed without any
> errors but when installing this package in the image it give some error
> like following. ERROR: hostapd not found in the base feeds (dhruwa_ioe
> mips32r2el mips32el mipsel noarch any all).

My advice here is to use the recipe we already have in the community to build 
this:

http://layers.openembedded.org/layerindex/branch/master/recipes/?q=hostapd

In general the OE layer index is the best place to find layers providing 
recipes to build anything that isn't already supplied in Poky/OE-core by 
default.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: UBIFS: Is it possible to get the compressed size of a file?

[hujianyang]

Hi Artem and Andreas,

I had worked on this feature for a few days. Now I meet some problems,
I want to discuss them with you and wish you could give me some advises.

On 2015/2/3 13:45, Andreas Dilger wrote:
> On Feb 2, 2015, at 2:33 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>>
>> Yes, no easy way, but I think implementing what you need is possible. I
>> do not have plans and time to work on this, but I can help by giving
>> advises and review.
>>
>> The question has 2 major parts.
>>
>> 1. The interface
>> 2. The implementation
>>
>> For the former, one need to carefully investigate if there is something
>> like this already implemented for other file-systems. I think btrfs may
>> have it. If it is, then UBIFS should use similar interface, probably.
>>
>> And whatever is the interface choice, it should be discussed in the
>> linux-fsdevel@vger.kernel.org mailing list, which I am CCing.
>

First, talking about the interface.

> One option that was discussed for btrfs was to use the first fe_reserved
> field for the FIEMAP ioctl struct fiemap_extent to fe_phys_length to
> hold the compressed size of each extent in the file.
>

I don't think fiemap is a good interface for UBIFS and for compressed
size reporting feature.

The contents of files in UBIFS are sorted into *ubifs_data_node* which
contains as much as UBIFS_BLOCK_SIZE(4096) bytes of data. A single file
may contain lots of data nodes and these data nodes may locate on flash
in order or in disorder because of out of place update.

An fiemap ioctl from userspace need lots of memory to store discontinuous
data mapping and copy these fiemap_extent may cost a lot of time.

> http://lwn.net/Articles/607552/
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> 
> I'm not sure what happened to that patch series - I was looking forward
> to it landing, and it was in very good shape I think.
> 

Since the *fe_phys_length* of fiemap_extent is not import to mainline,
current fiemap can only report logical data length of an extent. Regret
to say, it's no use for getting the compressed size of a file in UBIFS.


Then, looking at the implement.

>>
>> a. 'struct ubifs_ino_node' has unused space, use it to add the
>> compressed size field.
>> b. maintain this field
>> c. this field will only be correct for the part of the file which are on
>> the media. The dirty data in the page cache has not yet been compressed,
>> so we do not know its compressed size yet.
>> e. when user asks for the compressed size, you have to sync the inode
>> first, in order to make sure the compressed size is correct.
>>
>> And the implementation should be backward-compatible. That is, if new
>> driver mounts the old media, you return something predicatable. I guess
>> uncompressed size could be it.
>>

I'm worry about power cut recovery of compressed size if we introduce it
into 'struct ubifs_ino_node'. We can't write a new metadata node after each
changing of data node. Dirty data may not change the logical size of a file,
but it must change the compressed size. How to keep the consistency between
real compressed size(amount of each data nodes) and the record in metadata
node?

In logic size case, we could solve this problem by block number, because the
size of each blocks are UBIFS_BLOCK_SIZE, each exist data node could tell
the logic size of a file. Actually we use this method to fix the logic size
of a file in recovery path. Since the physic size of each data node are not
equal, we couldn't get the physic size of a file by a single data node in
journal. And we couldn't record the total compressed size of a file in data
node because it doesn't have enough reserve space, we couldn't use the same
functionality for compressed size.

Since metadata node(ubifs_ino_node) and data node(ubifs_data_node) are stored
in different journals, I didn't find a easy way to keep consistency when a
power cut happen. Seems a rebuilding whole scan can not be avoid in this case.


So could we use a simply method? just a private ioctl which scan the tnc tree
and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
but it is not import to mainline.

https://patchwork.kernel.org/patch/117782/

Since the files in UBIFS are not too large, maybe we could test if the cost of
time is acceptable for ordinary use case.

Further, for both fiemap or this private ioctl method, current tnc tree lookup
mechanism seems always copying the whole ubifs node, but only the header of a
node is used in this case. Do we have a way to only read part of a node from
tnc tree?

Thanks,
Hu

Re: UBIFS: Is it possible to get the compressed size of a file?

[hujianyang]

Hi Artem and Andreas,

I had worked on this feature for a few days. Now I meet some problems,
I want to discuss them with you and wish you could give me some advises.

On 2015/2/3 13:45, Andreas Dilger wrote:
> On Feb 2, 2015, at 2:33 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>>
>> Yes, no easy way, but I think implementing what you need is possible. I
>> do not have plans and time to work on this, but I can help by giving
>> advises and review.
>>
>> The question has 2 major parts.
>>
>> 1. The interface
>> 2. The implementation
>>
>> For the former, one need to carefully investigate if there is something
>> like this already implemented for other file-systems. I think btrfs may
>> have it. If it is, then UBIFS should use similar interface, probably.
>>
>> And whatever is the interface choice, it should be discussed in the
>> linux-fsdevel@vger.kernel.org mailing list, which I am CCing.
>

First, talking about the interface.

> One option that was discussed for btrfs was to use the first fe_reserved
> field for the FIEMAP ioctl struct fiemap_extent to fe_phys_length to
> hold the compressed size of each extent in the file.
>

I don't think fiemap is a good interface for UBIFS and for compressed
size reporting feature.

The contents of files in UBIFS are sorted into *ubifs_data_node* which
contains as much as UBIFS_BLOCK_SIZE(4096) bytes of data. A single file
may contain lots of data nodes and these data nodes may locate on flash
in order or in disorder because of out of place update.

An fiemap ioctl from userspace need lots of memory to store discontinuous
data mapping and copy these fiemap_extent may cost a lot of time.

> http://lwn.net/Articles/607552/
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> 
> I'm not sure what happened to that patch series - I was looking forward
> to it landing, and it was in very good shape I think.
> 

Since the *fe_phys_length* of fiemap_extent is not import to mainline,
current fiemap can only report logical data length of an extent. Regret
to say, it's no use for getting the compressed size of a file in UBIFS.


Then, looking at the implement.

>>
>> a. 'struct ubifs_ino_node' has unused space, use it to add the
>> compressed size field.
>> b. maintain this field
>> c. this field will only be correct for the part of the file which are on
>> the media. The dirty data in the page cache has not yet been compressed,
>> so we do not know its compressed size yet.
>> e. when user asks for the compressed size, you have to sync the inode
>> first, in order to make sure the compressed size is correct.
>>
>> And the implementation should be backward-compatible. That is, if new
>> driver mounts the old media, you return something predicatable. I guess
>> uncompressed size could be it.
>>

I'm worry about power cut recovery of compressed size if we introduce it
into 'struct ubifs_ino_node'. We can't write a new metadata node after each
changing of data node. Dirty data may not change the logical size of a file,
but it must change the compressed size. How to keep the consistency between
real compressed size(amount of each data nodes) and the record in metadata
node?

In logic size case, we could solve this problem by block number, because the
size of each blocks are UBIFS_BLOCK_SIZE, each exist data node could tell
the logic size of a file. Actually we use this method to fix the logic size
of a file in recovery path. Since the physic size of each data node are not
equal, we couldn't get the physic size of a file by a single data node in
journal. And we couldn't record the total compressed size of a file in data
node because it doesn't have enough reserve space, we couldn't use the same
functionality for compressed size.

Since metadata node(ubifs_ino_node) and data node(ubifs_data_node) are stored
in different journals, I didn't find a easy way to keep consistency when a
power cut happen. Seems a rebuilding whole scan can not be avoid in this case.


So could we use a simply method? just a private ioctl which scan the tnc tree
and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
but it is not import to mainline.

https://patchwork.kernel.org/patch/117782/

Since the files in UBIFS are not too large, maybe we could test if the cost of
time is acceptable for ordinary use case.

Further, for both fiemap or this private ioctl method, current tnc tree lookup
mechanism seems always copying the whole ubifs node, but only the header of a
node is used in this case. Do we have a way to only read part of a node from
tnc tree?

Thanks,
Hu

SDK generation issue

[Raghavendra Kakarla]

Hi Paul Eggleton,
Thanks for your help in the solving the issue for adding the bsp to yocto.
Now I am working on the yocto sdk generation.

I am generated the yocto SDK using the yocto sdk script "bitbake core-image-minimal -c populate_sdk" command. With this command I am able to generte the installation script file and .manifest file.

I run the installation script file. After running installation script file it propts that following message:

Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.


After this i run the ". /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got the correct path.

After this i built wrote a small example and try to build with the sdk generated toolchain by running following command:

mipsel-poky-linux-gcc test.c

but i got the following errors:
**************************************************************************************************************************************************
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crt1.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crti.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtbegin.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtend.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status

***********************************************************************************************************************************************************
Please help me to resolving this issue.

Thanks in advance.

Cheers,

Raghavendra Kakarla.

Re: SDK generation issue

[Paul Eggleton]

On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> I am generated the yocto SDK using the yocto sdk script "bitbake
> core-image-minimal -c populate_sdk" command. With this command I am able to
> generte the installation script file and .manifest file.
> 
> I run the installation script file. After running installation script file
> it propts that following message:
> 
> Extracting SDK...done
> Setting it up...done
> SDK has been successfully set up and is ready to be used.
> 
> 
> After this i run the ".
> /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> the correct path.
> 
> After this i built wrote a small example and try to build with the sdk
> generated toolchain by running following command:
> 
> mipsel-poky-linux-gcc test.c

Use $CC instead of running the compiler directly so that you get the correct 
options.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Raghavendra Kakarla]

Hi Paul Eggleton,

Thank you for your response.

Now my issue is resolved.

I have some doubts on yocto-sdk. Can you please clarify them.

When i Built SDK for YOCTO, I am getting a cross compilation tool chain. With which i am able to build the applications for my platform. I wanted to confirm, whether SDK means  a toolchain to build the applications or is there something more (such as documentation, libraries, etc generated for our platform) 

Regards,
Raghavendra.

From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Tuesday, March 3, 2015 3:07 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: SDK generation issue

On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> I am generated the yocto SDK using the yocto sdk script "bitbake
> core-image-minimal -c populate_sdk" command. With this command I am able to
> generte the installation script file and .manifest file.
>
> I run the installation script file. After running installation script file
> it propts that following message:
>
> Extracting SDK...done
> Setting it up...done
> SDK has been successfully set up and is ready to be used.
>
>
> After this i run the ".
> /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> the correct path.
>
> After this i built wrote a small example and try to build with the sdk
> generated toolchain by running following command:
>
> mipsel-poky-linux-gcc test.c

Use $CC instead of running the compiler directly so that you get the correct
options.

Cheers,
Paul


--

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Paul Eggleton]

On Tuesday 03 March 2015 10:26:46 Raghavendra Kakarla wrote:
> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> With which i am able to build the applications for my platform. I wanted to
> confirm, whether SDK means  a toolchain to build the applications or is
> there something more (such as documentation, libraries, etc generated for
> our platform)

The SDK will contain all libraries, headers and debugging symbols for the 
contents of the image specified with -c populate_sdk. It won't contain any 
documentation by default, though you could add it by setting SDKIMAGE_FEATURES 
e.g. 

SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs doc-pkgs"

(the default value set with ??= is "dev-pkgs dbg-pkgs")

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Raghavendra Kakarla]

Hi Paul Eggleton,

Where can i get the documents generated by the yocto sdk.

Regards,
Raghavendra.
________________________________________
From: Raghavendra Kakarla
Sent: Tuesday, March 3, 2015 3:56 PM
To: Paul Eggleton
Cc: yocto@yoctoproject.org
Subject: RE: SDK generation issue

Hi Paul Eggleton,

Thank you for your response.

Now my issue is resolved.

I have some doubts on yocto-sdk. Can you please clarify them.

When i Built SDK for YOCTO, I am getting a cross compilation tool chain. With which i am able to build the applications for my platform. I wanted to confirm, whether SDK means  a toolchain to build the applications or is there something more (such as documentation, libraries, etc generated for our platform)

Regards,
Raghavendra.

From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Tuesday, March 3, 2015 3:07 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: SDK generation issue

On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> I am generated the yocto SDK using the yocto sdk script "bitbake
> core-image-minimal -c populate_sdk" command. With this command I am able to
> generte the installation script file and .manifest file.
>
> I run the installation script file. After running installation script file
> it propts that following message:
>
> Extracting SDK...done
> Setting it up...done
> SDK has been successfully set up and is ready to be used.
>
>
> After this i run the ".
> /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> the correct path.
>
> After this i built wrote a small example and try to build with the sdk
> generated toolchain by running following command:
>
> mipsel-poky-linux-gcc test.c

Use $CC instead of running the compiler directly so that you get the correct
options.

Cheers,
Paul


--

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Paul Eggleton]

Assuming you built the SDK you had installed with "doc-pkgs" in 
SDKIMAGE_FEATURES, they would be in the target sysroot i.e. 
<sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/

On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Where can i get the documents generated by the yocto sdk.
> 
> Regards,
> Raghavendra.
> ________________________________________
> From: Raghavendra Kakarla
> Sent: Tuesday, March 3, 2015 3:56 PM
> To: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: SDK generation issue
> 
> Hi Paul Eggleton,
> 
> Thank you for your response.
> 
> Now my issue is resolved.
> 
> I have some doubts on yocto-sdk. Can you please clarify them.
> 
> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> With which i am able to build the applications for my platform. I wanted to
> confirm, whether SDK means  a toolchain to build the applications or is
> there something more (such as documentation, libraries, etc generated for
> our platform)
> 
> Regards,
> Raghavendra.
> 
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 3:07 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
> 
> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> > I am generated the yocto SDK using the yocto sdk script "bitbake
> > core-image-minimal -c populate_sdk" command. With this command I am able
> > to
> > generte the installation script file and .manifest file.
> > 
> > I run the installation script file. After running installation script file
> > it propts that following message:
> > 
> > Extracting SDK...done
> > Setting it up...done
> > SDK has been successfully set up and is ready to be used.
> > 
> > 
> > After this i run the ".
> > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> > the correct path.
> > 
> > After this i built wrote a small example and try to build with the sdk
> > generated toolchain by running following command:
> > 
> > mipsel-poky-linux-gcc test.c
> 
> Use $CC instead of running the compiler directly so that you get the correct
> options.
> 
> Cheers,
> Paul
> 
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Raghavendra Kakarla]

Hi Paul Eggleton,

Shall i get any API information in the generated SDK documents.

Regards,
Raghavendra.
________________________________________
From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Tuesday, March 3, 2015 5:40 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: SDK generation issue

Assuming you built the SDK you had installed with "doc-pkgs" in
SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
<sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/

On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
>
> Where can i get the documents generated by the yocto sdk.
>
> Regards,
> Raghavendra.
> ________________________________________
> From: Raghavendra Kakarla
> Sent: Tuesday, March 3, 2015 3:56 PM
> To: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: SDK generation issue
>
> Hi Paul Eggleton,
>
> Thank you for your response.
>
> Now my issue is resolved.
>
> I have some doubts on yocto-sdk. Can you please clarify them.
>
> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> With which i am able to build the applications for my platform. I wanted to
> confirm, whether SDK means  a toolchain to build the applications or is
> there something more (such as documentation, libraries, etc generated for
> our platform)
>
> Regards,
> Raghavendra.
>
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 3:07 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
>
> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> > I am generated the yocto SDK using the yocto sdk script "bitbake
> > core-image-minimal -c populate_sdk" command. With this command I am able
> > to
> > generte the installation script file and .manifest file.
> >
> > I run the installation script file. After running installation script file
> > it propts that following message:
> >
> > Extracting SDK...done
> > Setting it up...done
> > SDK has been successfully set up and is ready to be used.
> >
> >
> > After this i run the ".
> > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> > the correct path.
> >
> > After this i built wrote a small example and try to build with the sdk
> > generated toolchain by running following command:
> >
> > mipsel-poky-linux-gcc test.c
>
> Use $CC instead of running the compiler directly so that you get the correct
> options.
>
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

--

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Paul Eggleton]

Maybe, it depends on the individual projects. We haven't embarked upon any 
documentation standardisation effort.

On Tuesday 03 March 2015 12:17:45 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
> 
> Shall i get any API information in the generated SDK documents.
> 
> Regards,
> Raghavendra.
> ________________________________________
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 5:40 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
> 
> Assuming you built the SDK you had installed with "doc-pkgs" in
> SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
> <sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/
> 
> On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
> > Hi Paul Eggleton,
> > 
> > Where can i get the documents generated by the yocto sdk.
> > 
> > Regards,
> > Raghavendra.
> > ________________________________________
> > From: Raghavendra Kakarla
> > Sent: Tuesday, March 3, 2015 3:56 PM
> > To: Paul Eggleton
> > Cc: yocto@yoctoproject.org
> > Subject: RE: SDK generation issue
> > 
> > Hi Paul Eggleton,
> > 
> > Thank you for your response.
> > 
> > Now my issue is resolved.
> > 
> > I have some doubts on yocto-sdk. Can you please clarify them.
> > 
> > When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> > With which i am able to build the applications for my platform. I wanted
> > to
> > confirm, whether SDK means  a toolchain to build the applications or is
> > there something more (such as documentation, libraries, etc generated for
> > our platform)
> > 
> > Regards,
> > Raghavendra.
> > 
> > From: Paul Eggleton <paul.eggleton@linux.intel.com>
> > Sent: Tuesday, March 3, 2015 3:07 PM
> > To: Raghavendra Kakarla
> > Cc: yocto@yoctoproject.org
> > Subject: Re: SDK generation issue
> > 
> > On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> > > I am generated the yocto SDK using the yocto sdk script "bitbake
> > > core-image-minimal -c populate_sdk" command. With this command I am able
> > > to
> > > generte the installation script file and .manifest file.
> > > 
> > > I run the installation script file. After running installation script
> > > file
> > > it propts that following message:
> > > 
> > > Extracting SDK...done
> > > Setting it up...done
> > > SDK has been successfully set up and is ready to be used.
> > > 
> > > 
> > > After this i run the ".
> > > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i
> > > got
> > > the correct path.
> > > 
> > > After this i built wrote a small example and try to build with the sdk
> > > generated toolchain by running following command:
> > > 
> > > mipsel-poky-linux-gcc test.c
> > 
> > Use $CC instead of running the compiler directly so that you get the
> > correct options.
> > 
> > Cheers,
> > Paul
> > 
> > 
> > --
> > 
> > Paul Eggleton
> > Intel Open Source Technology Centre
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK generation issue

[Jim Rafert]

Try doing:

${CC} test.c

This will invoke the cross compiler with all the compilation flags required to produce
an executable for the target, using libraries on the target root file system.



________________________________________
From: Raghavendra Kakarla [Raghavendra.Kakarla@inedasystems.com]
Sent: Monday, March 02, 2015 10:41 PM
To: Paul Eggleton
Cc: yocto@yoctoproject.org
Subject: [yocto] SDK generation issue

Hi Paul Eggleton,
Thanks for your help in the solving the issue for adding the bsp to yocto.
Now I am working on the yocto sdk generation.

I am generated the yocto SDK using the yocto sdk script "bitbake core-image-minimal -c populate_sdk" command. With this command I am able to generte the installation script file and .manifest file.

I run the installation script file. After running installation script file it propts that following message:

Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.


After this i run the ". /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got the correct path.

After this i built wrote a small example and try to build with the sdk generated toolchain by running following command:

mipsel-poky-linux-gcc test.c

but i got the following errors:
**************************************************************************************************************************************************
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crt1.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crti.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtbegin.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find -lgcc_s
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtend.o: No such file or directory
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/4.9.1/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status

***********************************************************************************************************************************************************
Please help me to resolving this issue.

Thanks in advance.

Cheers,

Raghavendra Kakarla.

Difference b/w yocto kernels and normal linux.org kernels

[Raghavendra Kakarla]

Hi Paul Eggleton,
I have some doubt that is ,there is any difference between the linux kernels downloaded from the yocto and that are download from the kernel.org with same version number?
Can you please clarify the my doubt.

Thanks and Regards,
Raghavendra Kakarla__________________________________
______
From: Raghavendra Kakarla
Sent: Tuesday, March 3, 2015 5:47 PM
To: Paul Eggleton
Cc: yocto@yoctoproject.org
Subject: RE: SDK generation issue

Hi Paul Eggleton,

Shall i get any API information in the generated SDK documents.

Regards,
Raghavendra.
________________________________________
From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Tuesday, March 3, 2015 5:40 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: SDK generation issue

Assuming you built the SDK you had installed with "doc-pkgs" in
SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
<sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/

On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
>
> Where can i get the documents generated by the yocto sdk.
>
> Regards,
> Raghavendra.
> ________________________________________
> From: Raghavendra Kakarla
> Sent: Tuesday, March 3, 2015 3:56 PM
> To: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: SDK generation issue
>
> Hi Paul Eggleton,
>
> Thank you for your response.
>
> Now my issue is resolved.
>
> I have some doubts on yocto-sdk. Can you please clarify them.
>
> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> With which i am able to build the applications for my platform. I wanted to
> confirm, whether SDK means  a toolchain to build the applications or is
> there something more (such as documentation, libraries, etc generated for
> our platform)
>
> Regards,
> Raghavendra.
>
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 3:07 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
>
> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> > I am generated the yocto SDK using the yocto sdk script "bitbake
> > core-image-minimal -c populate_sdk" command. With this command I am able
> > to
> > generte the installation script file and .manifest file.
> >
> > I run the installation script file. After running installation script file
> > it propts that following message:
> >
> > Extracting SDK...done
> > Setting it up...done
> > SDK has been successfully set up and is ready to be used.
> >
> >
> > After this i run the ".
> > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> > the correct path.
> >
> > After this i built wrote a small example and try to build with the sdk
> > generated toolchain by running following command:
> >
> > mipsel-poky-linux-gcc test.c
>
> Use $CC instead of running the compiler directly so that you get the correct
> options.
>
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

--

Paul Eggleton
Intel Open Source Technology Centre

Re: Difference b/w yocto kernels and normal linux.org kernels

[Khem Raj]

> On Mar 9, 2015, at 9:21 PM, Raghavendra Kakarla <Raghavendra.Kakarla@inedasystems.com> wrote:
> 
> Hi Paul Eggleton,
> I have some doubt that is ,there is any difference between the linux kernels downloaded from the yocto and that are download from the kernel.org with same version number?
> Can you please clarify the my doubt.
> 

Yocto project provides a reference kernel called linux-yocto hosted at https://git.yoctoproject.org/ search for "Yocto Linux Kernel”
you will find the trees for various versions. The root of linux-yocto is linux-stable from kernel.org. Then there are device specific branches where the reference BSPs are using to build the reference kernel. So yes there are differences where linux-yocto might have back ported or forward ported patches to get a given machine working on a given kernel version. On top it has its own tooling to help you create kernel build infrastructure for new machine that you might be working on.
there is extensive documentation and training on developing with linux-yocto as kernel. The branches eg.

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.19/refs/heads

However the OE infrastructure ( which yocto project uses for its build system), does not bind you to use linux-yocto, infact it provides base classes which help you to write your own recipes for kernel you would like to have. So you can very well you a different kernel.

> Thanks and Regards,
> Raghavendra Kakarla__________________________________
> ______
> From: Raghavendra Kakarla
> Sent: Tuesday, March 3, 2015 5:47 PM
> To: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: SDK generation issue
> 
> Hi Paul Eggleton,
> 
> Shall i get any API information in the generated SDK documents.
> 
> Regards,
> Raghavendra.
> ________________________________________
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 5:40 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
> 
> Assuming you built the SDK you had installed with "doc-pkgs" in
> SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
> <sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/
> 
> On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
>> Hi Paul Eggleton,
>> 
>> Where can i get the documents generated by the yocto sdk.
>> 
>> Regards,
>> Raghavendra.
>> ________________________________________
>> From: Raghavendra Kakarla
>> Sent: Tuesday, March 3, 2015 3:56 PM
>> To: Paul Eggleton
>> Cc: yocto@yoctoproject.org
>> Subject: RE: SDK generation issue
>> 
>> Hi Paul Eggleton,
>> 
>> Thank you for your response.
>> 
>> Now my issue is resolved.
>> 
>> I have some doubts on yocto-sdk. Can you please clarify them.
>> 
>> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
>> With which i am able to build the applications for my platform. I wanted to
>> confirm, whether SDK means  a toolchain to build the applications or is
>> there something more (such as documentation, libraries, etc generated for
>> our platform)
>> 
>> Regards,
>> Raghavendra.
>> 
>> From: Paul Eggleton <paul.eggleton@linux.intel.com>
>> Sent: Tuesday, March 3, 2015 3:07 PM
>> To: Raghavendra Kakarla
>> Cc: yocto@yoctoproject.org
>> Subject: Re: SDK generation issue
>> 
>> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
>>> I am generated the yocto SDK using the yocto sdk script "bitbake
>>> core-image-minimal -c populate_sdk" command. With this command I am able
>>> to
>>> generte the installation script file and .manifest file.
>>> 
>>> I run the installation script file. After running installation script file
>>> it propts that following message:
>>> 
>>> Extracting SDK...done
>>> Setting it up...done
>>> SDK has been successfully set up and is ready to be used.
>>> 
>>> 
>>> After this i run the ".
>>> /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
>>> the correct path.
>>> 
>>> After this i built wrote a small example and try to build with the sdk
>>> generated toolchain by running following command:
>>> 
>>> mipsel-poky-linux-gcc test.c
>> 
>> Use $CC instead of running the compiler directly so that you get the correct
>> options.
>> 
>> Cheers,
>> Paul
>> 
>> 
>> --
>> 
>> Paul Eggleton
>> Intel Open Source Technology Centre
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Difference b/w yocto kernels and normal linux.org kernels

[Nicholas Krause]

On March 10, 2015 12:33:14 AM EDT, Khem Raj <raj.khem@gmail.com> wrote:
>
>
>
>> On Mar 9, 2015, at 9:21 PM, Raghavendra Kakarla
><Raghavendra.Kakarla@inedasystems.com> wrote:
>> 
>> Hi Paul Eggleton,
>> I have some doubt that is ,there is any difference between the linux
>kernels downloaded from the yocto and that are download from the
>kernel.org with same version number?
>> Can you please clarify the my doubt.
>> 
>
>Yocto project provides a reference kernel called linux-yocto hosted at
>https://git.yoctoproject.org/ search for "Yocto Linux Kernel”
>you will find the trees for various versions. The root of linux-yocto
>is linux-stable from kernel.org. Then there are device specific
>branches where the reference BSPs are using to build the reference
>kernel. So yes there are differences where linux-yocto might have back
>ported or forward ported patches to get a given machine working on a
>given kernel version. On top it has its own tooling to help you create
>kernel build infrastructure for new machine that you might be working
>on.
>there is extensive documentation and training on developing with
>linux-yocto as kernel. The branches eg.
>
>https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.19/refs/heads
>
>However the OE infrastructure ( which yocto project uses for its build
>system), does not bind you to use linux-yocto, infact it provides base
>classes which help you to write your own recipes for kernel you would
>like to have. So you can very well you a different kernel.
>
>> Thanks and Regards,
>> Raghavendra Kakarla__________________________________
>> ______
I would recommend looking into the reference docs for kernel building and programming under documents in the yocto project's main website for more information on how to build or custom your kernel using recipe files.  Furthermore Raghavendra is right to my knowledge in how the yocto project is different from the mainline kernel trees,  however if you wish you can still use them. 
Nick
>> From: Raghavendra Kakarla
>> Sent: Tuesday, March 3, 2015 5:47 PM
>> To: Paul Eggleton
>> Cc: yocto@yoctoproject.org
>> Subject: RE: SDK generation issue
>> 
>> Hi Paul Eggleton,
>> 
>> Shall i get any API information in the generated SDK documents.
>> 
>> Regards,
>> Raghavendra.
>> ________________________________________
>> From: Paul Eggleton <paul.eggleton@linux.intel.com>
>> Sent: Tuesday, March 3, 2015 5:40 PM
>> To: Raghavendra Kakarla
>> Cc: yocto@yoctoproject.org
>> Subject: Re: SDK generation issue
>> 
>> Assuming you built the SDK you had installed with "doc-pkgs" in
>> SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
>> <sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/
>> 
>> On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
>>> Hi Paul Eggleton,
>>> 
>>> Where can i get the documents generated by the yocto sdk.
>>> 
>>> Regards,
>>> Raghavendra.
>>> ________________________________________
>>> From: Raghavendra Kakarla
>>> Sent: Tuesday, March 3, 2015 3:56 PM
>>> To: Paul Eggleton
>>> Cc: yocto@yoctoproject.org
>>> Subject: RE: SDK generation issue
>>> 
>>> Hi Paul Eggleton,
>>> 
>>> Thank you for your response.
>>> 
>>> Now my issue is resolved.
>>> 
>>> I have some doubts on yocto-sdk. Can you please clarify them.
>>> 
>>> When i Built SDK for YOCTO, I am getting a cross compilation tool
>chain.
>>> With which i am able to build the applications for my platform. I
>wanted to
>>> confirm, whether SDK means  a toolchain to build the applications or
>is
>>> there something more (such as documentation, libraries, etc
>generated for
>>> our platform)
>>> 
>>> Regards,
>>> Raghavendra.
>>> 
>>> From: Paul Eggleton <paul.eggleton@linux.intel.com>
>>> Sent: Tuesday, March 3, 2015 3:07 PM
>>> To: Raghavendra Kakarla
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: SDK generation issue
>>> 
>>> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
>>>> I am generated the yocto SDK using the yocto sdk script "bitbake
>>>> core-image-minimal -c populate_sdk" command. With this command I am
>able
>>>> to
>>>> generte the installation script file and .manifest file.
>>>> 
>>>> I run the installation script file. After running installation
>script file
>>>> it propts that following message:
>>>> 
>>>> Extracting SDK...done
>>>> Setting it up...done
>>>> SDK has been successfully set up and is ready to be used.
>>>> 
>>>> 
>>>> After this i run the ".
>>>> /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo
>$PATH i got
>>>> the correct path.
>>>> 
>>>> After this i built wrote a small example and try to build with the
>sdk
>>>> generated toolchain by running following command:
>>>> 
>>>> mipsel-poky-linux-gcc test.c
>>> 
>>> Use $CC instead of running the compiler directly so that you get the
>correct
>>> options.
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> 
>>> --
>>> 
>>> Paul Eggleton
>>> Intel Open Source Technology Centre
>> 
>> --
>> 
>> Paul Eggleton
>> Intel Open Source Technology Centre
>> -- 
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>-- 
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

OpenStack - Libvirt+Xen CI overview

[Bob Ball]

For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.

The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
- Puppet to deploy the master node
- Zuul to watch for code changes uploaded to review.openstack.org
- Jenkins job builder to create Jenkins job definitions from a YAML file
- Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
- Devstack-gate to run Tempest tests in serial

More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org

The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/

In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.

Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html

I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!

Thanks,

Bob

Re: Difference b/w yocto kernels and normal linux.org kernels

[Raghavendra Kakarla]

Hi Paul Eggleton,

Is it kernel is must be a git repository code for building in the yocto?

When i gave my custom kernel which is not a git repository code and it is in my development PC, i got invalid SRCREV number error.
But when give the same kernel from the git repository it is working.
Can you please help me in resolving this error.  

Cheers,
Raghavendra K.
________________________________________
From: Raghavendra Kakarla
Sent: Tuesday, March 10, 2015 9:51 AM
To: Paul Eggleton
Cc: yocto@yoctoproject.org
Subject: Difference b/w yocto kernels and normal linux.org kernels

Hi Paul Eggleton,
I have some doubt that is ,there is any difference between the linux kernels downloaded from the yocto and that are download from the kernel.org with same version number?
Can you please clarify the my doubt.

Thanks and Regards,
Raghavendra Kakarla__________________________________
______
From: Raghavendra Kakarla
Sent: Tuesday, March 3, 2015 5:47 PM
To: Paul Eggleton
Cc: yocto@yoctoproject.org
Subject: RE: SDK generation issue

Hi Paul Eggleton,

Shall i get any API information in the generated SDK documents.

Regards,
Raghavendra.
________________________________________
From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Tuesday, March 3, 2015 5:40 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: SDK generation issue

Assuming you built the SDK you had installed with "doc-pkgs" in
SDKIMAGE_FEATURES, they would be in the target sysroot i.e.
<sdk-install-dir>/sysroots/<your-machine-arch>/usr/share/doc/

On Tuesday 03 March 2015 11:55:22 Raghavendra Kakarla wrote:
> Hi Paul Eggleton,
>
> Where can i get the documents generated by the yocto sdk.
>
> Regards,
> Raghavendra.
> ________________________________________
> From: Raghavendra Kakarla
> Sent: Tuesday, March 3, 2015 3:56 PM
> To: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Subject: RE: SDK generation issue
>
> Hi Paul Eggleton,
>
> Thank you for your response.
>
> Now my issue is resolved.
>
> I have some doubts on yocto-sdk. Can you please clarify them.
>
> When i Built SDK for YOCTO, I am getting a cross compilation tool chain.
> With which i am able to build the applications for my platform. I wanted to
> confirm, whether SDK means  a toolchain to build the applications or is
> there something more (such as documentation, libraries, etc generated for
> our platform)
>
> Regards,
> Raghavendra.
>
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Tuesday, March 3, 2015 3:07 PM
> To: Raghavendra Kakarla
> Cc: yocto@yoctoproject.org
> Subject: Re: SDK generation issue
>
> On Tuesday 03 March 2015 05:41:43 Raghavendra Kakarla wrote:
> > I am generated the yocto SDK using the yocto sdk script "bitbake
> > core-image-minimal -c populate_sdk" command. With this command I am able
> > to
> > generte the installation script file and .manifest file.
> >
> > I run the installation script file. After running installation script file
> > it propts that following message:
> >
> > Extracting SDK...done
> > Setting it up...done
> > SDK has been successfully set up and is ready to be used.
> >
> >
> > After this i run the ".
> > /opt/poky/1.7/environment-setup-mips32rel-poky-linux" and echo $PATH i got
> > the correct path.
> >
> > After this i built wrote a small example and try to build with the sdk
> > generated toolchain by running following command:
> >
> > mipsel-poky-linux-gcc test.c
>
> Use $CC instead of running the compiler directly so that you get the correct
> options.
>
> Cheers,
> Paul
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

--

Paul Eggleton
Intel Open Source Technology Centre

Re: Difference b/w yocto kernels and normal linux.org kernels

[Paul Eggleton]

On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote:
> Is it kernel is must be a git repository code for building in the yocto?
> 
> When i gave my custom kernel which is not a git repository code and it is in
> my development PC, i got invalid SRCREV number error. But when give the
> same kernel from the git repository it is working. Can you please help me
> in resolving this error.

If you want to use your own non-git sources you are moving further away from
how the linux-yocto recipe works. If you have not already I would suggest
using linux-yocto-custom as described in our kernel development manual:

http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources

Note that you must not have SRCPV included in the recipe's value of PV, or
you will get the error you mentioned.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Difference b/w yocto kernels and normal linux.org kernels

[Albert K]

Hi Paul,

I hope you don't mind me asking a question slightly out of topic.  I
would like to know if there is a recipe for linux kernel 3.19 for
dizzy branch (intel x64).  Thanks.

Regards,
Albert.

On Fri, Mar 13, 2015 at 4:53 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote:
>> Is it kernel is must be a git repository code for building in the yocto?
>>
>> When i gave my custom kernel which is not a git repository code and it is in
>> my development PC, i got invalid SRCREV number error. But when give the
>> same kernel from the git repository it is working. Can you please help me
>> in resolving this error.
>
> If you want to use your own non-git sources you are moving further away from
> how the linux-yocto recipe works. If you have not already I would suggest
> using linux-yocto-custom as described in our kernel development manual:
>
> http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources
>
> Note that you must not have SRCPV included in the recipe's value of PV, or
> you will get the error you mentioned.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Difference b/w yocto kernels and normal linux.org kernels

[Paul Eggleton]

On Friday 13 March 2015 17:05:29 Albert K wrote:
> I hope you don't mind me asking a question slightly out of topic.  I
> would like to know if there is a recipe for linux kernel 3.19 for
> dizzy branch (intel x64).  Thanks.

No, not out of the box - 3.19 wasn't available at the time dizzy (1.7) was 
branched and we don't generally backport upgrades. That said it should be 
fairly easy to build your own newer kernel by adding your own recipe to do so 
(though there may possibly be user-space compatibility issues you need to 
resolve as a result - I'm no expert there).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Lars Kurth]

Bob,

adding the Test WG. 

As so far no-one has responded to your offer to organise an on-line meeting to walk interested parties the CI loop. If you are, please reply to this thread.

If no-one comes back, I am wondering whether it may not be better to put some wiki pages together explaining how the the CI loop works, how to read the results, what log files to get to investigate issues, etc. ... For someone unfamiliar with Jenkins, this is not entirely obvious.

And maybe have a separate status page. 

I could then take the material it and put a blog post together.

Regards
Lars

> On 10 Mar 2015, at 12:03, Bob Ball <bob.ball@citrix.com> wrote:
> 
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
> 
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
> - Devstack-gate to run Tempest tests in serial
> 
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
> 
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
> 
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
> 
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
> 
> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> 
> Thanks,
> 
> Bob
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview

[Konrad Rzeszutek Wilk]

On Tue, Mar 10, 2015 at 12:03:13PM +0000, Bob Ball wrote:
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
> 
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
> - Devstack-gate to run Tempest tests in serial
> 
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
> 
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
> 
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
> 
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
> 
> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> 

I am always interested in it.
> Thanks,
> 
> Bob
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview

[George Dunlap]

On Tue, Mar 10, 2015 at 12:03 PM, Bob Ball <bob.ball@citrix.com> wrote:
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
>
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud
> - Devstack-gate to run Tempest tests in serial
>
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
>
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
>
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
>
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
>
> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!

I'd be interested.

 -George

Re: OpenStack - Libvirt+Xen CI overview

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 507 bytes --]

On Mon, 2015-03-16 at 14:00 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 10, 2015 at 12:03:13PM +0000, Bob Ball wrote:

> > I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> > 
> 
> I am always interested in it.
>
I know next to nothing about OpenStack, and would be interested in
attending something like this to improve that. :-)

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview

[Jim Fehlig]

Bob Ball wrote:
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
>
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
> - Devstack-gate to run Tempest tests in serial
>
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
>
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
>
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
>
>   
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for
> a passing job at
> http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html

Thanks for the info!

>   
> I'd like to organise a meeting to walk through the various components
> of the CI with those who are interested, so this is an initial call to
> find out who is interested in finding out more!

I'd like to know more.

Regards,
Jim

Re: OpenStack - Libvirt+Xen CI overview

[Alvin Starr]

On 03/10/2015 08:03 AM, Bob Ball wrote:
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
>
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud
> - Devstack-gate to run Tempest tests in serial
>
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
>
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
>
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
>
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
>
> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
>
> Thanks,
>
> Bob
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
I would also love to find out more.


-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
alvin@netvel.net              ||

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Lars Kurth]

Hi,

I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets.

I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone.

Best Regards
Lars

Begin forwarded message:

From: Bob Ball <bob.ball@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: 10 March 2015 12:03:13 GMT
Cc: Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview

For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.

The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
- Puppet to deploy the master node
- Zuul to watch for code changes uploaded to review.openstack.org
- Jenkins job builder to create Jenkins job definitions from a YAML file
- Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
- Devstack-gate to run Tempest tests in serial

More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org

The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/

In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.

Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html

I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!

Thanks,

Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Wei Liu]

On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> Hi,
> 
> I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets.
> 
> I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone.
> 

I would be interested in such meeting. My time zone is the same as
George's and Anthony's.

Wei.

> Best Regards
> Lars
> 
> Begin forwarded message:
> 
> From: Bob Ball <bob.ball@citrix.com>
> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> Date: 10 March 2015 12:03:13 GMT
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> 
> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
> 
> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> - Puppet to deploy the master node
> - Zuul to watch for code changes uploaded to review.openstack.org
> - Jenkins job builder to create Jenkins job definitions from a YAML file
> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
> - Devstack-gate to run Tempest tests in serial
> 
> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
> 
> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
> 
> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
> 
> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
> 
> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> 
> Thanks,
> 
> Bob
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Lars Kurth]

I propose to set this up for the week of April 14th or the week after. A lot of people are on Easter vacation/holiday before
Lars

> On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
>> Hi,
>> 
>> I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets.
>> 
>> I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone.
>> 
> 
> I would be interested in such meeting. My time zone is the same as
> George's and Anthony's.
> 
> Wei.
> 
>> Best Regards
>> Lars
>> 
>> Begin forwarded message:
>> 
>> From: Bob Ball <bob.ball@citrix.com>
>> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
>> Date: 10 March 2015 12:03:13 GMT
>> Cc: Anthony Perard <anthony.perard@citrix.com>
>> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
>> 
>> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
>> 
>> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
>> - Puppet to deploy the master node
>> - Zuul to watch for code changes uploaded to review.openstack.org
>> - Jenkins job builder to create Jenkins job definitions from a YAML file
>> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
>> - Devstack-gate to run Tempest tests in serial
>> 
>> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
>> 
>> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
>> 
>> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
>> 
>> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
>> 
>> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
>> 
>> Thanks,
>> 
>> Bob
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Ian Campbell]

FWIW there's the regular technical call slot on the 8th, but a) that's
earlier and Easter vac and b) I'm on PTO myself at the time, but if you
are interested we could use that (the whole point was to take some of
the burden off arranging ad-hoc calls).

Ian.

On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> I propose to set this up for the week of April 14th or the week after. A lot of people are on Easter vacation/holiday before
> Lars
> 
> > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > 
> > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> >> Hi,
> >> 
> >> I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets.
> >> 
> >> I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone.
> >> 
> > 
> > I would be interested in such meeting. My time zone is the same as
> > George's and Anthony's.
> > 
> > Wei.
> > 
> >> Best Regards
> >> Lars
> >> 
> >> Begin forwarded message:
> >> 
> >> From: Bob Ball <bob.ball@citrix.com>
> >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> >> Date: 10 March 2015 12:03:13 GMT
> >> Cc: Anthony Perard <anthony.perard@citrix.com>
> >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> >> 
> >> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
> >> 
> >> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> >> - Puppet to deploy the master node
> >> - Zuul to watch for code changes uploaded to review.openstack.org
> >> - Jenkins job builder to create Jenkins job definitions from a YAML file
> >> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud 
> >> - Devstack-gate to run Tempest tests in serial
> >> 
> >> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
> >> 
> >> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
> >> 
> >> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
> >> 
> >> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
> >> 
> >> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> >> 
> >> Thanks,
> >> 
> >> Bob
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Bob Ball]

Unfortunately I'm also on vacation on the 8th - so I don't think that slot won't work very well this time round!

Bob
________________________________________
From: Ian Campbell [ian.campbell@citrix.com]
Sent: 25 March 2015 10:08
To: Lars Kurth
Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-framework@lists.xenproject.org
Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

FWIW there's the regular technical call slot on the 8th, but a) that's
earlier and Easter vac and b) I'm on PTO myself at the time, but if you
are interested we could use that (the whole point was to take some of
the burden off arranging ad-hoc calls).

Ian.

On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> I propose to set this up for the week of April 14th or the week after. A lot of people are on Easter vacation/holiday before
> Lars
>
> > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> >> Hi,
> >>
> >> I added all the people who raised their hands so far to the TO list. As far as I can tell we have people from the following timezones: GMT, GMT+1, MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending on when we have the presentation, we will need to consider daylight savings offsets.
> >>
> >> I will give it another few days for more people to raise their hands. We can then try and figure out a slot which fits everyone.
> >>
> >
> > I would be interested in such meeting. My time zone is the same as
> > George's and Anthony's.
> >
> > Wei.
> >
> >> Best Regards
> >> Lars
> >>
> >> Begin forwarded message:
> >>
> >> From: Bob Ball <bob.ball@citrix.com>
> >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> >> Date: 10 March 2015 12:03:13 GMT
> >> Cc: Anthony Perard <anthony.perard@citrix.com>
> >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> >>
> >> For the last few weeks Anthony and I have been working on creating a CI environment to run against all OpenStack jobs.  We're now in a position where we can share the current status, overview of how it works and next steps.  We actively want to support involvement in this effort from others with an interest in libvirt+Xen's openstack integration.
> >>
> >> The CI we have set up is follow the recommendations made by the OpenStack official infrastructure maintainers, and reproduces a notable portion of the official OpenStack CI environment to run these tests.  Namely this setup is using:
> >> - Puppet to deploy the master node
> >> - Zuul to watch for code changes uploaded to review.openstack.org
> >> - Jenkins job builder to create Jenkins job definitions from a YAML file
> >> - Nodepool to automatically create single-use virtual machines in the Rackspace public cloud
> >> - Devstack-gate to run Tempest tests in serial
> >>
> >> More information on Zuul, JJB, Nodepool and devstack-gate is available through http://ci.openstack.org
> >>
> >> The current status is that we have a zuul instance monitoring for jobs and adding them to the queue of jobs to be run at http://zuul.openstack.xenproject.org/
> >>
> >> In the background Nodepool provisions virtual machines into a pool of nodes ready to be used.  All ready nodes are automatically added to Jenkins (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will trigger a particular job on a node when one is available.
> >>
> >> Logs are then uploaded to Rackspace's Cloud Files with sample logs for a passing job at http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-xen/da3ff30/index.html
> >>
> >> I'd like to organise a meeting to walk through the various components of the CI with those who are interested, so this is an initial call to find out who is interested in finding out more!
> >>
> >> Thanks,
> >>
> >> Bob
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Alvin Starr]

I will be away till  April 23  so it looks like I will miss this.

On 03/25/2015 06:09 AM, Bob Ball wrote:
> Unfortunately I'm also on vacation on the 8th - so I don't think that slot won't work very well this time round!
>
> Bob
> ________________________________________
> From: Ian Campbell [ian.campbell@citrix.com]
> Sent: 25 March 2015 10:08
> To: Lars Kurth
> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-framework@lists.xenproject.org
> Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works
>
> FWIW there's the regular technical call slot on the 8th, but a) that's
> earlier and Easter vac and b) I'm on PTO myself at the time, but if you
> are interested we could use that (the whole point was to take some of
> the burden off arranging ad-hoc calls).
>
> Ian.
>
[snip]

-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
alvin@netvel.net              ||

Re: UBIFS: Is it possible to get the compressed size of a file?

[David Sterba]

On Sat, Feb 28, 2015 at 03:31:14PM +0800, hujianyang wrote:
> > http://lwn.net/Articles/607552/
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> > 
> > I'm not sure what happened to that patch series - I was looking forward
> > to it landing, and it was in very good shape I think.

> Since the *fe_phys_length* of fiemap_extent is not import to mainline,
> current fiemap can only report logical data length of an extent. Regret
> to say, it's no use for getting the compressed size of a file in UBIFS.

Yeah, not the best example how a patchset should be pushed. I'll try to
get back soon to it given the almost-ready state and another potential
user of the interface.

> So could we use a simply method? just a private ioctl which scan the tnc tree
> and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
> but it is not import to mainline.
> 
> https://patchwork.kernel.org/patch/117782/

This was at the beginning of the fiemap extensions. I've picked that
patch, updated and sent

http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg14371.html

but it was not merged. We've discussed that and came to conclusion that
a special ioctl was not the right approach when we could extend the
existing interfaces. The ioctl was iterating over all extents and just
summing some numbers, effectively repeating the core code of fiemap.

Though you're (relatively) free to introduce private ioctls for your
filesystem, I'd rather not recommend that. Once an ioctl is introduced,
you have to support it forever, the deprecation periods span several
years.

> Further, for both fiemap or this private ioctl method, current tnc tree lookup
> mechanism seems always copying the whole ubifs node, but only the header of a
> node is used in this case. Do we have a way to only read part of a node from
> tnc tree?

I don't understand the details, but this seems that even the private
ioctl would help too much even if you'd be more free to do some
performance optimizations that would not fit fiemap.

Re: UBIFS: Is it possible to get the compressed size of a file?

[David Sterba]

On Sat, Feb 28, 2015 at 03:31:14PM +0800, hujianyang wrote:
> > http://lwn.net/Articles/607552/
> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/37312
> > 
> > I'm not sure what happened to that patch series - I was looking forward
> > to it landing, and it was in very good shape I think.

> Since the *fe_phys_length* of fiemap_extent is not import to mainline,
> current fiemap can only report logical data length of an extent. Regret
> to say, it's no use for getting the compressed size of a file in UBIFS.

Yeah, not the best example how a patchset should be pushed. I'll try to
get back soon to it given the almost-ready state and another potential
user of the interface.

> So could we use a simply method? just a private ioctl which scan the tnc tree
> and report the compressed size of a UBIFS file? I found an old patch for Btrfs,
> but it is not import to mainline.
> 
> https://patchwork.kernel.org/patch/117782/

This was at the beginning of the fiemap extensions. I've picked that
patch, updated and sent

http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg14371.html

but it was not merged. We've discussed that and came to conclusion that
a special ioctl was not the right approach when we could extend the
existing interfaces. The ioctl was iterating over all extents and just
summing some numbers, effectively repeating the core code of fiemap.

Though you're (relatively) free to introduce private ioctls for your
filesystem, I'd rather not recommend that. Once an ioctl is introduced,
you have to support it forever, the deprecation periods span several
years.

> Further, for both fiemap or this private ioctl method, current tnc tree lookup
> mechanism seems always copying the whole ubifs node, but only the header of a
> node is used in this case. Do we have a way to only read part of a node from
> tnc tree?

I don't understand the details, but this seems that even the private
ioctl would help too much even if you'd be more free to do some
performance optimizations that would not fit fiemap.

Re: Difference b/w yocto kernels and normal linux.org kernels

[Raghavendra Kakarla]

Hi Paul Eggleton,

I have some doubts on the SDK and build errors.

Could you please clarify my doubts.

1. Can we get the consolidated log/file for total installed packages for corresponding SDK. If user wants to know what packages are included in the SDK.

2. When trying to build the images always getting a error saying that clean things in kernel path in build error log, then we goto that path run command "make mrproper" then it is working fine. 


Thanks and Regards,
Raghavendra K.


________________________________________
From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Friday, March 13, 2015 2:23 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: Difference b/w yocto kernels and normal linux.org kernels

On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote:
> Is it kernel is must be a git repository code for building in the yocto?
>
> When i gave my custom kernel which is not a git repository code and it is in
> my development PC, i got invalid SRCREV number error. But when give the
> same kernel from the git repository it is working. Can you please help me
> in resolving this error.

If you want to use your own non-git sources you are moving further away from
how the linux-yocto recipe works. If you have not already I would suggest
using linux-yocto-custom as described in our kernel development manual:

http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources

Note that you must not have SRCPV included in the recipe's value of PV, or
you will get the error you mentioned.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Lars Kurth]

Hi folks, 

last week we were focussed on getting http://jenkins.openstack.xenproject.org/view/Dashboard/builds into a decent state, so we decided to defer this. Now most of the tests have been in green status for a few days, so it may make sense to arrange a day and time. With the timezones in questions, probably an hour from 
* 15:00 to 17:00 slot in the UK 
* 16:00 to 18:00 in mainland Europe
* 08:00 to 10:00 in MTZ
* 10:00 to 12:00 in ETZ 

Next week is challenging as we have the Hackathon in China. How about we aim for a day in the week of May 4th (it will have to be a Tue to Thu though as we have a public holiday in the UK on the 4th)

Regards
Lars


> On 25 Mar 2015, at 12:26, Alvin Starr <alvin@netvel.net> wrote:
> 
> I will be away till  April 23  so it looks like I will miss this.
> 
> On 03/25/2015 06:09 AM, Bob Ball wrote:
>> Unfortunately I'm also on vacation on the 8th - so I don't think that slot won't work very well this time round!
>> 
>> Bob
>> ________________________________________
>> From: Ian Campbell [ian.campbell@citrix.com]
>> Sent: 25 March 2015 10:08
>> To: Lars Kurth
>> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-framework@lists.xenproject.org
>> Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works
>> 
>> FWIW there's the regular technical call slot on the 8th, but a) that's
>> earlier and Easter vac and b) I'm on PTO myself at the time, but if you
>> are interested we could use that (the whole point was to take some of
>> the burden off arranging ad-hoc calls).
>> 
>> Ian.
>> 
> [snip]
> 
> -- 
> Alvin Starr                   ||   voice: (905)513-7688
> Netvel Inc.                   ||   Cell:  (416)806-0133
> alvin@netvel.net              ||
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Bob Ball]

Hi all,

Apologies for dropping the ball on this.

I've created a doodle poll with an initial set of options at http://doodle.com/596a39y9t9dhah65.  The timezone is currently set to London (BST) but can be changed on the link to your local timezone.

If there are others who would like to attend this walkthrough where either the suggested meeting times don't match their timezone or can't make any of the suggested dates, let us know.

Thanks!

Bob 

> -----Original Message-----
> From: Bob Ball
> Sent: 25 March 2015 10:10
> To: Ian Campbell; Lars Kurth
> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> devel; Jim Fehlig; Anthony Perard; wg-test-framework@lists.xenproject.org
> Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> interested in a walk/through or presentation on how it works
> 
> Unfortunately I'm also on vacation on the 8th - so I don't think that slot
> won't work very well this time round!
> 
> Bob
> ________________________________________
> From: Ian Campbell [ian.campbell@citrix.com]
> Sent: 25 March 2015 10:08
> To: Lars Kurth
> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-
> framework@lists.xenproject.org
> Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> interested in a walk/through or presentation on how it works
> 
> FWIW there's the regular technical call slot on the 8th, but a) that's
> earlier and Easter vac and b) I'm on PTO myself at the time, but if you
> are interested we could use that (the whole point was to take some of
> the burden off arranging ad-hoc calls).
> 
> Ian.
> 
> On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> > I propose to set this up for the week of April 14th or the week after. A lot
> of people are on Easter vacation/holiday before
> > Lars
> >
> > > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > >
> > > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> > >> Hi,
> > >>
> > >> I added all the people who raised their hands so far to the TO list. As far
> as I can tell we have people from the following timezones: GMT, GMT+1,
> MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending
> on when we have the presentation, we will need to consider daylight
> savings offsets.
> > >>
> > >> I will give it another few days for more people to raise their hands. We
> can then try and figure out a slot which fits everyone.
> > >>
> > >
> > > I would be interested in such meeting. My time zone is the same as
> > > George's and Anthony's.
> > >
> > > Wei.
> > >
> > >> Best Regards
> > >> Lars
> > >>
> > >> Begin forwarded message:
> > >>
> > >> From: Bob Ball <bob.ball@citrix.com>
> > >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> > >> Date: 10 March 2015 12:03:13 GMT
> > >> Cc: Anthony Perard <anthony.perard@citrix.com>
> > >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> > >>
> > >> For the last few weeks Anthony and I have been working on creating a
> CI environment to run against all OpenStack jobs.  We're now in a position
> where we can share the current status, overview of how it works and next
> steps.  We actively want to support involvement in this effort from others
> with an interest in libvirt+Xen's openstack integration.
> > >>	
> > >> The CI we have set up is follow the recommendations made by the
> OpenStack official infrastructure maintainers, and reproduces a notable
> portion of the official OpenStack CI environment to run these tests.  Namely
> this setup is using:
> > >> - Puppet to deploy the master node
> > >> - Zuul to watch for code changes uploaded to review.openstack.org
> > >> - Jenkins job builder to create Jenkins job definitions from a YAML file
> > >> - Nodepool to automatically create single-use virtual machines in the
> Rackspace public cloud
> > >> - Devstack-gate to run Tempest tests in serial
> > >>
> > >> More information on Zuul, JJB, Nodepool and devstack-gate is available
> through http://ci.openstack.org
> > >>
> > >> The current status is that we have a zuul instance monitoring for jobs
> and adding them to the queue of jobs to be run at
> http://zuul.openstack.xenproject.org/
> > >>
> > >> In the background Nodepool provisions virtual machines into a pool of
> nodes ready to be used.  All ready nodes are automatically added to Jenkins
> (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will
> trigger a particular job on a node when one is available.
> > >>
> > >> Logs are then uploaded to Rackspace's Cloud Files with sample logs for
> a passing job at
> http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-
> xen/da3ff30/index.html
> > >>
> > >> I'd like to organise a meeting to walk through the various components
> of the CI with those who are interested, so this is an initial call to find out
> who is interested in finding out more!
> > >>
> > >> Thanks,
> > >>
> > >> Bob
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@lists.xen.org
> > >> http://lists.xen.org/xen-devel
> > >>
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@lists.xen.org
> > >> http://lists.xen.org/xen-devel
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Lars Kurth]

Bob,

Thank you.

Adding Michael Glasgow

Note that I created a new list wg-openstack@lists.xenproject.org (CC'ed) , where we can discuss openstack related issues (see http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-openstack). I will link to it from various wiki/web pages also

Regards
Lars

> On 4 Jun 2015, at 18:12, Bob Ball <bob.ball@citrix.com> wrote:
> 
> Hi all,
> 
> Apologies for dropping the ball on this.
> 
> I've created a doodle poll with an initial set of options at http://doodle.com/596a39y9t9dhah65.  The timezone is currently set to London (BST) but can be changed on the link to your local timezone.
> 
> If there are others who would like to attend this walkthrough where either the suggested meeting times don't match their timezone or can't make any of the suggested dates, let us know.
> 
> Thanks!
> 
> Bob 
> 
>> -----Original Message-----
>> From: Bob Ball
>> Sent: 25 March 2015 10:10
>> To: Ian Campbell; Lars Kurth
>> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
>> devel; Jim Fehlig; Anthony Perard; wg-test-framework@lists.xenproject.org
>> Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
>> interested in a walk/through or presentation on how it works
>> 
>> Unfortunately I'm also on vacation on the 8th - so I don't think that slot
>> won't work very well this time round!
>> 
>> Bob
>> ________________________________________
>> From: Ian Campbell [ian.campbell@citrix.com]
>> Sent: 25 March 2015 10:08
>> To: Lars Kurth
>> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
>> devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-
>> framework@lists.xenproject.org
>> Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
>> interested in a walk/through or presentation on how it works
>> 
>> FWIW there's the regular technical call slot on the 8th, but a) that's
>> earlier and Easter vac and b) I'm on PTO myself at the time, but if you
>> are interested we could use that (the whole point was to take some of
>> the burden off arranging ad-hoc calls).
>> 
>> Ian.
>> 
>> On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
>>> I propose to set this up for the week of April 14th or the week after. A lot
>> of people are on Easter vacation/holiday before
>>> Lars
>>> 
>>>> On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
>>>> 
>>>> On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
>>>>> Hi,
>>>>> 
>>>>> I added all the people who raised their hands so far to the TO list. As far
>> as I can tell we have people from the following timezones: GMT, GMT+1,
>> MTZ, ETZ - if I got this wrong, please let me know your timezone. Depending
>> on when we have the presentation, we will need to consider daylight
>> savings offsets.
>>>>> 
>>>>> I will give it another few days for more people to raise their hands. We
>> can then try and figure out a slot which fits everyone.
>>>>> 
>>>> 
>>>> I would be interested in such meeting. My time zone is the same as
>>>> George's and Anthony's.
>>>> 
>>>> Wei.
>>>> 
>>>>> Best Regards
>>>>> Lars
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: Bob Ball <bob.ball@citrix.com>
>>>>> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
>>>>> Date: 10 March 2015 12:03:13 GMT
>>>>> Cc: Anthony Perard <anthony.perard@citrix.com>
>>>>> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
>>>>> 
>>>>> For the last few weeks Anthony and I have been working on creating a
>> CI environment to run against all OpenStack jobs.  We're now in a position
>> where we can share the current status, overview of how it works and next
>> steps.  We actively want to support involvement in this effort from others
>> with an interest in libvirt+Xen's openstack integration.
>>>>> 	
>>>>> The CI we have set up is follow the recommendations made by the
>> OpenStack official infrastructure maintainers, and reproduces a notable
>> portion of the official OpenStack CI environment to run these tests.  Namely
>> this setup is using:
>>>>> - Puppet to deploy the master node
>>>>> - Zuul to watch for code changes uploaded to review.openstack.org
>>>>> - Jenkins job builder to create Jenkins job definitions from a YAML file
>>>>> - Nodepool to automatically create single-use virtual machines in the
>> Rackspace public cloud
>>>>> - Devstack-gate to run Tempest tests in serial
>>>>> 
>>>>> More information on Zuul, JJB, Nodepool and devstack-gate is available
>> through http://ci.openstack.org
>>>>> 
>>>>> The current status is that we have a zuul instance monitoring for jobs
>> and adding them to the queue of jobs to be run at
>> http://zuul.openstack.xenproject.org/
>>>>> 
>>>>> In the background Nodepool provisions virtual machines into a pool of
>> nodes ready to be used.  All ready nodes are automatically added to Jenkins
>> (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will
>> trigger a particular job on a node when one is available.
>>>>> 
>>>>> Logs are then uploaded to Rackspace's Cloud Files with sample logs for
>> a passing job at
>> http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-
>> xen/da3ff30/index.html
>>>>> 
>>>>> I'd like to organise a meeting to walk through the various components
>> of the CI with those who are interested, so this is an initial call to find out
>> who is interested in finding out more!
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Bob
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>> 
> 

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Bob Ball]

Hi all,

Currently the favoured option is Monday 15th at 16:00 BST.  If this option doesn't work for you, please participate in the poll ASAP.  I will send out confirmation of the date on Wednesday 10th.

Thanks,

Bob

> -----Original Message-----
> From: Bob Ball
> Sent: 04 June 2015 18:11
> To: Ian Campbell; Lars Kurth
> Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> devel; Jim Fehlig; Anthony Perard; wg-test-framework@lists.xenproject.org
> Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> interested in a walk/through or presentation on how it works
> 
> Hi all,
> 
> Apologies for dropping the ball on this.
> 
> I've created a doodle poll with an initial set of options at
> http://doodle.com/596a39y9t9dhah65.  The timezone is currently set to
> London (BST) but can be changed on the link to your local timezone.
> 
> If there are others who would like to attend this walkthrough where either
> the suggested meeting times don't match their timezone or can't make any
> of the suggested dates, let us know.
> 
> Thanks!
> 
> Bob
> 
> > -----Original Message-----
> > From: Bob Ball
> > Sent: 25 March 2015 10:10
> > To: Ian Campbell; Lars Kurth
> > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> > devel; Jim Fehlig; Anthony Perard; wg-test-
> framework@lists.xenproject.org
> > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > interested in a walk/through or presentation on how it works
> >
> > Unfortunately I'm also on vacation on the 8th - so I don't think that slot
> > won't work very well this time round!
> >
> > Bob
> > ________________________________________
> > From: Ian Campbell [ian.campbell@citrix.com]
> > Sent: 25 March 2015 10:08
> > To: Lars Kurth
> > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> > devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-
> > framework@lists.xenproject.org
> > Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > interested in a walk/through or presentation on how it works
> >
> > FWIW there's the regular technical call slot on the 8th, but a) that's
> > earlier and Easter vac and b) I'm on PTO myself at the time, but if you
> > are interested we could use that (the whole point was to take some of
> > the burden off arranging ad-hoc calls).
> >
> > Ian.
> >
> > On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> > > I propose to set this up for the week of April 14th or the week after. A lot
> > of people are on Easter vacation/holiday before
> > > Lars
> > >
> > > > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > > >
> > > > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> > > >> Hi,
> > > >>
> > > >> I added all the people who raised their hands so far to the TO list. As
> far
> > as I can tell we have people from the following timezones: GMT, GMT+1,
> > MTZ, ETZ - if I got this wrong, please let me know your timezone.
> Depending
> > on when we have the presentation, we will need to consider daylight
> > savings offsets.
> > > >>
> > > >> I will give it another few days for more people to raise their hands.
> We
> > can then try and figure out a slot which fits everyone.
> > > >>
> > > >
> > > > I would be interested in such meeting. My time zone is the same as
> > > > George's and Anthony's.
> > > >
> > > > Wei.
> > > >
> > > >> Best Regards
> > > >> Lars
> > > >>
> > > >> Begin forwarded message:
> > > >>
> > > >> From: Bob Ball <bob.ball@citrix.com>
> > > >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> > > >> Date: 10 March 2015 12:03:13 GMT
> > > >> Cc: Anthony Perard <anthony.perard@citrix.com>
> > > >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> > > >>
> > > >> For the last few weeks Anthony and I have been working on creating a
> > CI environment to run against all OpenStack jobs.  We're now in a position
> > where we can share the current status, overview of how it works and next
> > steps.  We actively want to support involvement in this effort from others
> > with an interest in libvirt+Xen's openstack integration.
> > > >>
> > > >> The CI we have set up is follow the recommendations made by the
> > OpenStack official infrastructure maintainers, and reproduces a notable
> > portion of the official OpenStack CI environment to run these tests.
> Namely
> > this setup is using:
> > > >> - Puppet to deploy the master node
> > > >> - Zuul to watch for code changes uploaded to review.openstack.org
> > > >> - Jenkins job builder to create Jenkins job definitions from a YAML file
> > > >> - Nodepool to automatically create single-use virtual machines in the
> > Rackspace public cloud
> > > >> - Devstack-gate to run Tempest tests in serial
> > > >>
> > > >> More information on Zuul, JJB, Nodepool and devstack-gate is
> available
> > through http://ci.openstack.org
> > > >>
> > > >> The current status is that we have a zuul instance monitoring for jobs
> > and adding them to the queue of jobs to be run at
> > http://zuul.openstack.xenproject.org/
> > > >>
> > > >> In the background Nodepool provisions virtual machines into a pool of
> > nodes ready to be used.  All ready nodes are automatically added to
> Jenkins
> > (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will
> > trigger a particular job on a node when one is available.
> > > >>
> > > >> Logs are then uploaded to Rackspace's Cloud Files with sample logs
> for
> > a passing job at
> > http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-tempest-
> > xen/da3ff30/index.html
> > > >>
> > > >> I'd like to organise a meeting to walk through the various components
> > of the CI with those who are interested, so this is an initial call to find out
> > who is interested in finding out more!
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Bob
> > > >>
> > > >> _______________________________________________
> > > >> Xen-devel mailing list
> > > >> Xen-devel@lists.xen.org
> > > >> http://lists.xen.org/xen-devel
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Xen-devel mailing list
> > > >> Xen-devel@lists.xen.org
> > > >> http://lists.xen.org/xen-devel
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> >

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Bob Ball]

I can confirm that the only option where all of the interested parties can meet is Monday 15th at 16:00 BST, so we'll fix that as the time.

I have set up a GoToMeeting to host this overview, details below.

1.  Please join my meeting.
https://global.gotomeeting.com/join/840676301

2.  Use your microphone and speakers (VoIP) - a headset is recommended.  Or, call in using your telephone.

United States (toll-free): 1 877 568 4106
Australia: +61 2 8355 1020
Canada: +1 (647) 497-9353
Hungary (toll-free): (06) 80 986 255
United Kingdom (toll-free): 0 800 169 0432
United Kingdom: +44 (0) 330 221 0088
United States: +1 (646) 749-3129

Access Code: 840-676-301
Audio PIN: Shown after joining the meeting

Everyone is welcome, even if they did not reply to the poll selecting a meeting time.

Thanks,

Bob

> -----Original Message-----
> From: Bob Ball
> Sent: 08 June 2015 13:52
> To: Ian Campbell; 'Lars Kurth'
> Cc: Wei Liu; 'Alvin Starr'; George Dunlap; Dario Faggioli; 'Russ Pavlicek'; 'xen-
> devel'; 'Jim Fehlig'; Anthony Perard; 'wg-test-
> framework@lists.xenproject.org'; 'wg-openstack@lists.xenproject.org'; Ant
> Messerli
> Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> interested in a walk/through or presentation on how it works
> 
> Hi all,
> 
> Currently the favoured option is Monday 15th at 16:00 BST.  If this option
> doesn't work for you, please participate in the poll ASAP.  I will send out
> confirmation of the date on Wednesday 10th.
> 
> Thanks,
> 
> Bob
> 
> > -----Original Message-----
> > From: Bob Ball
> > Sent: 04 June 2015 18:11
> > To: Ian Campbell; Lars Kurth
> > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek; xen-
> > devel; Jim Fehlig; Anthony Perard; wg-test-
> framework@lists.xenproject.org
> > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > interested in a walk/through or presentation on how it works
> >
> > Hi all,
> >
> > Apologies for dropping the ball on this.
> >
> > I've created a doodle poll with an initial set of options at
> > http://doodle.com/596a39y9t9dhah65.  The timezone is currently set to
> > London (BST) but can be changed on the link to your local timezone.
> >
> > If there are others who would like to attend this walkthrough where
> either
> > the suggested meeting times don't match their timezone or can't make
> any
> > of the suggested dates, let us know.
> >
> > Thanks!
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Bob Ball
> > > Sent: 25 March 2015 10:10
> > > To: Ian Campbell; Lars Kurth
> > > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek;
> xen-
> > > devel; Jim Fehlig; Anthony Perard; wg-test-
> > framework@lists.xenproject.org
> > > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > > interested in a walk/through or presentation on how it works
> > >
> > > Unfortunately I'm also on vacation on the 8th - so I don't think that slot
> > > won't work very well this time round!
> > >
> > > Bob
> > > ________________________________________
> > > From: Ian Campbell [ian.campbell@citrix.com]
> > > Sent: 25 March 2015 10:08
> > > To: Lars Kurth
> > > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek;
> xen-
> > > devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-
> > > framework@lists.xenproject.org
> > > Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > > interested in a walk/through or presentation on how it works
> > >
> > > FWIW there's the regular technical call slot on the 8th, but a) that's
> > > earlier and Easter vac and b) I'm on PTO myself at the time, but if you
> > > are interested we could use that (the whole point was to take some of
> > > the burden off arranging ad-hoc calls).
> > >
> > > Ian.
> > >
> > > On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> > > > I propose to set this up for the week of April 14th or the week after. A
> lot
> > > of people are on Easter vacation/holiday before
> > > > Lars
> > > >
> > > > > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > > > >
> > > > > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> > > > >> Hi,
> > > > >>
> > > > >> I added all the people who raised their hands so far to the TO list. As
> > far
> > > as I can tell we have people from the following timezones: GMT, GMT+1,
> > > MTZ, ETZ - if I got this wrong, please let me know your timezone.
> > Depending
> > > on when we have the presentation, we will need to consider daylight
> > > savings offsets.
> > > > >>
> > > > >> I will give it another few days for more people to raise their hands.
> > We
> > > can then try and figure out a slot which fits everyone.
> > > > >>
> > > > >
> > > > > I would be interested in such meeting. My time zone is the same as
> > > > > George's and Anthony's.
> > > > >
> > > > > Wei.
> > > > >
> > > > >> Best Regards
> > > > >> Lars
> > > > >>
> > > > >> Begin forwarded message:
> > > > >>
> > > > >> From: Bob Ball <bob.ball@citrix.com>
> > > > >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> > > > >> Date: 10 March 2015 12:03:13 GMT
> > > > >> Cc: Anthony Perard <anthony.perard@citrix.com>
> > > > >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> > > > >>
> > > > >> For the last few weeks Anthony and I have been working on creating
> a
> > > CI environment to run against all OpenStack jobs.  We're now in a
> position
> > > where we can share the current status, overview of how it works and
> next
> > > steps.  We actively want to support involvement in this effort from
> others
> > > with an interest in libvirt+Xen's openstack integration.
> > > > >>
> > > > >> The CI we have set up is follow the recommendations made by the
> > > OpenStack official infrastructure maintainers, and reproduces a notable
> > > portion of the official OpenStack CI environment to run these tests.
> > Namely
> > > this setup is using:
> > > > >> - Puppet to deploy the master node
> > > > >> - Zuul to watch for code changes uploaded to review.openstack.org
> > > > >> - Jenkins job builder to create Jenkins job definitions from a YAML
> file
> > > > >> - Nodepool to automatically create single-use virtual machines in
> the
> > > Rackspace public cloud
> > > > >> - Devstack-gate to run Tempest tests in serial
> > > > >>
> > > > >> More information on Zuul, JJB, Nodepool and devstack-gate is
> > available
> > > through http://ci.openstack.org
> > > > >>
> > > > >> The current status is that we have a zuul instance monitoring for jobs
> > > and adding them to the queue of jobs to be run at
> > > http://zuul.openstack.xenproject.org/
> > > > >>
> > > > >> In the background Nodepool provisions virtual machines into a pool
> of
> > > nodes ready to be used.  All ready nodes are automatically added to
> > Jenkins
> > > (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins will
> > > trigger a particular job on a node when one is available.
> > > > >>
> > > > >> Logs are then uploaded to Rackspace's Cloud Files with sample logs
> > for
> > > a passing job at
> > > http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-
> tempest-
> > > xen/da3ff30/index.html
> > > > >>
> > > > >> I'd like to organise a meeting to walk through the various
> components
> > > of the CI with those who are interested, so this is an initial call to find
> out
> > > who is interested in finding out more!
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Bob
> > > > >>
> > > > >> _______________________________________________
> > > > >> Xen-devel mailing list
> > > > >> Xen-devel@lists.xen.org
> > > > >> http://lists.xen.org/xen-devel
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> Xen-devel mailing list
> > > > >> Xen-devel@lists.xen.org
> > > > >> http://lists.xen.org/xen-devel
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > >

Re: OpenStack - Libvirt+Xen CI overview : anyone interested in a walk/through or presentation on how it works

[Bob Ball]

Hi everyone,

Thanks for joining the call today.  Lars has uploaded the slides presented to http://www.slideshare.net/xen_com_mgr/xen-project-ci-for-openstack-overview so they can be referenced there.

If anyone has further questions about the CI, how it is set up, or how they can be involved please just shout.

Thanks!

Bob

> -----Original Message-----
> From: Bob Ball
> Sent: 10 June 2015 15:25
> To: Ian Campbell; 'Lars Kurth'
> Cc: Wei Liu; 'Alvin Starr'; George Dunlap; Dario Faggioli; 'Russ Pavlicek'; 'xen-
> devel'; 'Jim Fehlig'; Anthony Perard; 'wg-test-
> framework@lists.xenproject.org'; 'wg-openstack@lists.xenproject.org'; Ant
> Messerli
> Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> interested in a walk/through or presentation on how it works
> 
> I can confirm that the only option where all of the interested parties can
> meet is Monday 15th at 16:00 BST, so we'll fix that as the time.
> 
> I have set up a GoToMeeting to host this overview, details below.
> 
> 1.  Please join my meeting.
> https://global.gotomeeting.com/join/840676301
> 
> 2.  Use your microphone and speakers (VoIP) - a headset is recommended.
> Or, call in using your telephone.
> 
> United States (toll-free): 1 877 568 4106
> Australia: +61 2 8355 1020
> Canada: +1 (647) 497-9353
> Hungary (toll-free): (06) 80 986 255
> United Kingdom (toll-free): 0 800 169 0432
> United Kingdom: +44 (0) 330 221 0088
> United States: +1 (646) 749-3129
> 
> Access Code: 840-676-301
> Audio PIN: Shown after joining the meeting
> 
> Everyone is welcome, even if they did not reply to the poll selecting a
> meeting time.
> 
> Thanks,
> 
> Bob
> 
> > -----Original Message-----
> > From: Bob Ball
> > Sent: 08 June 2015 13:52
> > To: Ian Campbell; 'Lars Kurth'
> > Cc: Wei Liu; 'Alvin Starr'; George Dunlap; Dario Faggioli; 'Russ Pavlicek';
> 'xen-
> > devel'; 'Jim Fehlig'; Anthony Perard; 'wg-test-
> > framework@lists.xenproject.org'; 'wg-openstack@lists.xenproject.org';
> Ant
> > Messerli
> > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > interested in a walk/through or presentation on how it works
> >
> > Hi all,
> >
> > Currently the favoured option is Monday 15th at 16:00 BST.  If this option
> > doesn't work for you, please participate in the poll ASAP.  I will send out
> > confirmation of the date on Wednesday 10th.
> >
> > Thanks,
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Bob Ball
> > > Sent: 04 June 2015 18:11
> > > To: Ian Campbell; Lars Kurth
> > > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek;
> xen-
> > > devel; Jim Fehlig; Anthony Perard; wg-test-
> > framework@lists.xenproject.org
> > > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > > interested in a walk/through or presentation on how it works
> > >
> > > Hi all,
> > >
> > > Apologies for dropping the ball on this.
> > >
> > > I've created a doodle poll with an initial set of options at
> > > http://doodle.com/596a39y9t9dhah65.  The timezone is currently set to
> > > London (BST) but can be changed on the link to your local timezone.
> > >
> > > If there are others who would like to attend this walkthrough where
> > either
> > > the suggested meeting times don't match their timezone or can't make
> > any
> > > of the suggested dates, let us know.
> > >
> > > Thanks!
> > >
> > > Bob
> > >
> > > > -----Original Message-----
> > > > From: Bob Ball
> > > > Sent: 25 March 2015 10:10
> > > > To: Ian Campbell; Lars Kurth
> > > > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek;
> > xen-
> > > > devel; Jim Fehlig; Anthony Perard; wg-test-
> > > framework@lists.xenproject.org
> > > > Subject: RE: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > > > interested in a walk/through or presentation on how it works
> > > >
> > > > Unfortunately I'm also on vacation on the 8th - so I don't think that slot
> > > > won't work very well this time round!
> > > >
> > > > Bob
> > > > ________________________________________
> > > > From: Ian Campbell [ian.campbell@citrix.com]
> > > > Sent: 25 March 2015 10:08
> > > > To: Lars Kurth
> > > > Cc: Wei Liu; Alvin Starr; George Dunlap; Dario Faggioli; Russ Pavlicek;
> > xen-
> > > > devel; Jim Fehlig; Anthony Perard; Bob Ball; wg-test-
> > > > framework@lists.xenproject.org
> > > > Subject: Re: [Xen-devel] OpenStack - Libvirt+Xen CI overview : anyone
> > > > interested in a walk/through or presentation on how it works
> > > >
> > > > FWIW there's the regular technical call slot on the 8th, but a) that's
> > > > earlier and Easter vac and b) I'm on PTO myself at the time, but if you
> > > > are interested we could use that (the whole point was to take some of
> > > > the burden off arranging ad-hoc calls).
> > > >
> > > > Ian.
> > > >
> > > > On Tue, 2015-03-24 at 18:17 +0000, Lars Kurth wrote:
> > > > > I propose to set this up for the week of April 14th or the week after. A
> > lot
> > > > of people are on Easter vacation/holiday before
> > > > > Lars
> > > > >
> > > > > > On 18 Mar 2015, at 14:37, Wei Liu <wei.liu2@citrix.com> wrote:
> > > > > >
> > > > > > On Wed, Mar 18, 2015 at 01:12:50PM +0000, Lars Kurth wrote:
> > > > > >> Hi,
> > > > > >>
> > > > > >> I added all the people who raised their hands so far to the TO list.
> As
> > > far
> > > > as I can tell we have people from the following timezones: GMT,
> GMT+1,
> > > > MTZ, ETZ - if I got this wrong, please let me know your timezone.
> > > Depending
> > > > on when we have the presentation, we will need to consider daylight
> > > > savings offsets.
> > > > > >>
> > > > > >> I will give it another few days for more people to raise their hands.
> > > We
> > > > can then try and figure out a slot which fits everyone.
> > > > > >>
> > > > > >
> > > > > > I would be interested in such meeting. My time zone is the same as
> > > > > > George's and Anthony's.
> > > > > >
> > > > > > Wei.
> > > > > >
> > > > > >> Best Regards
> > > > > >> Lars
> > > > > >>
> > > > > >> Begin forwarded message:
> > > > > >>
> > > > > >> From: Bob Ball <bob.ball@citrix.com>
> > > > > >> To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> > > > > >> Date: 10 March 2015 12:03:13 GMT
> > > > > >> Cc: Anthony Perard <anthony.perard@citrix.com>
> > > > > >> Subject: [Xen-devel] OpenStack - Libvirt+Xen CI overview
> > > > > >>
> > > > > >> For the last few weeks Anthony and I have been working on
> creating
> > a
> > > > CI environment to run against all OpenStack jobs.  We're now in a
> > position
> > > > where we can share the current status, overview of how it works and
> > next
> > > > steps.  We actively want to support involvement in this effort from
> > others
> > > > with an interest in libvirt+Xen's openstack integration.
> > > > > >>
> > > > > >> The CI we have set up is follow the recommendations made by the
> > > > OpenStack official infrastructure maintainers, and reproduces a
> notable
> > > > portion of the official OpenStack CI environment to run these tests.
> > > Namely
> > > > this setup is using:
> > > > > >> - Puppet to deploy the master node
> > > > > >> - Zuul to watch for code changes uploaded to review.openstack.org
> > > > > >> - Jenkins job builder to create Jenkins job definitions from a YAML
> > file
> > > > > >> - Nodepool to automatically create single-use virtual machines in
> > the
> > > > Rackspace public cloud
> > > > > >> - Devstack-gate to run Tempest tests in serial
> > > > > >>
> > > > > >> More information on Zuul, JJB, Nodepool and devstack-gate is
> > > available
> > > > through http://ci.openstack.org
> > > > > >>
> > > > > >> The current status is that we have a zuul instance monitoring for
> jobs
> > > > and adding them to the queue of jobs to be run at
> > > > http://zuul.openstack.xenproject.org/
> > > > > >>
> > > > > >> In the background Nodepool provisions virtual machines into a
> pool
> > of
> > > > nodes ready to be used.  All ready nodes are automatically added to
> > > Jenkins
> > > > (https://jenkins.openstack.xenproject.org/), and then Zuul+Jenkins
> will
> > > > trigger a particular job on a node when one is available.
> > > > > >>
> > > > > >> Logs are then uploaded to Rackspace's Cloud Files with sample logs
> > > for
> > > > a passing job at
> > > > http://logs.openstack.xenproject.org/52/162352/3/silent/dsvm-
> > tempest-
> > > > xen/da3ff30/index.html
> > > > > >>
> > > > > >> I'd like to organise a meeting to walk through the various
> > components
> > > > of the CI with those who are interested, so this is an initial call to find
> > out
> > > > who is interested in finding out more!
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Bob
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Xen-devel mailing list
> > > > > >> Xen-devel@lists.xen.org
> > > > > >> http://lists.xen.org/xen-devel
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Xen-devel mailing list
> > > > > >> Xen-devel@lists.xen.org
> > > > > >> http://lists.xen.org/xen-devel
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xen.org
> > > > > http://lists.xen.org/xen-devel
> > > >