Hi Eduardo, On Tue, Apr 15, 2008 at 3:25 AM, Eduardo Valentin <edubezval@xxxxxxxxx> wrote: > Hi Trilok and Hari, > > > On Mon, Apr 14, 2008 at 4:58 AM, Trilok Soni <soni.trilok@xxxxxxxxx> wrote: > > Hi Hari, > > > > > > On Wed, Apr 9, 2008 at 12:33 AM, Kanigeri, Hari <h-kanigeri2@xxxxxx> wrote: > > > Hi Trilok, > > > > > > > > > > 1. Is this a complete re-write of TI internal dspbridge release to > > > > confirm with linux kernel coding standards? I have heard that internal > > > > > > > TI bridge is more of layered code and not confirming to Linux kernel > > > > coding standards. > > > It is layered code and most of the code is up to date with Linux Kernel > > > > > > Coding standards. > > > > > > > 2. Does this package has DOFF/COFF format loader? > > > yes, this package includes DOFF/COFF format loader. > > > > > > > Thanks for the reply. As you have opened the doff format. Could you > > please put document explaining the architecture of this format? I > > mean, just a simple table by explaining which block follows whom and > > pointer to other blocks. e.g. section(s) -> string table -> data etc. > > > > As I can see that this DOFF loader has been written in kernel-space, > > any special reasons for such design? It could have been simply written > > in userspace and then after parsing and based on cpu-state we could > > have just copied the required sections into targets memory/or bunch of > > co-processors memory. > > I agree here. If I understood correctlu, moving this code to kernel space would > only make it complex. If you put this in user land, kernel code will > be more independent from formats. > Just memory handling code would be necessary into kernel side to > implement this feature. > Moved CC to linux-omap@vger list. Sorry for replying earlier to old ML, I totally forgot. Actually by bringing doff loader to userspace, we can later integrate that with libbfd in binutils, and loading could become even simpler. -- ---Trilok Soni http://triloksoni.wordpress.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
