Re: MIPS toolchain

On Fri, 29 Jul 2011 11:12:35 -0400 James Jones mentioned: > Does anyone have a prebuilt MIPS tool chain? > If you're looking to build standalone applications (like uboot), try devel/mips-rtems-gcc (or devel/cross-gcc if you don't like rtems patches). It should work fine for building uboot or o

Re: Capsicum project: Ideas needed

On Fri, 8 Jul 2011 15:09:52 +0400 "Ilya Bakulin" mentioned: > [CCing Ben, Robert and Jonathan as it's very important for me to receive > their feedback about my thoughts] > > Let me focus on those application ideas that you've mentioned. All the > following are my thoughts and this may be incorr

How to include without "device_if.h" and "bus_if.h"?

Hello, Freebsd-hackers. I need to include in my kernel module to use devctl_notify(). But my module doesn't have device_if.h or bus_if.h, which are required by . What should I do? -- // Black Lion AKA Lev Serebryakov ___ freebsd-hackers@freebsd.

Re: How to include without "device_if.h" and "bus_if.h"?

Just add them to the makefile. They'll be automatically created as dependencies. 2011/9/8 Lev Serebryakov : > Hello, Freebsd-hackers. > >  I need to include in my kernel module to use > devctl_notify(). But my module doesn't have device_if.h or bus_if.h, > which are required by . >  What should

Re: How to include without "device_if.h" and "bus_if.h"?

Hello, K.. You wrote 8 сентября 2011 г., 18:22:11: > Just add them to the makefile. They'll be automatically created as > dependencies. Is it good idea to create these empty files only for one prototype from ? Why devctl_notify() is bound to bus, anyway? It is used, for example, for notificati

Re: How to include without "device_if.h" and "bus_if.h"?

2011/9/8 Lev Serebryakov : > Hello, K.. > You wrote 8 сентября 2011 г., 18:22:11: > >> Just add them to the makefile. They'll be automatically created  as >> dependencies. >  Is it good idea to create these empty files only for one prototype > from ? I can't comment on whether or not it is good or

Soliciting opinions on an extension of the bootinfo structure

I'm proposing an extension framework for the bootinfo structure used to pass information from the bootstrap/loader to the kernel. Although I'm only proposing this for the MIPS bootinfo, it's completely applicable to any of them. What I propose is adding an optional platform extension structure:

Porting PathScale's EKOPath Compiler Suite

I have done preliminary porting work of PathScale's open-sourced EKOPath Compiler Suite (https://github.com/pathscale). http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 This includes experimental OpenMP support and PathDB. Unfortuntely, PathDB builds fine but just crashes ATM. Both optio

Re: Soliciting opinions on an extension of the bootinfo structure

I'm proposing an extension framework for the bootinfo structure used to pass information from the bootstrap/loader to the kernel. Although I'm only proposing this for the MIPS bootinfo, it's completely applicable to any of them. What I propose is adding an optional platform extension structure: b

Re: Porting PathScale's EKOPath Compiler Suite

On 09/ 9/11 05:11 AM, Jung-uk Kim wrote: I have done preliminary porting work of PathScale's open-sourced EKOPath Compiler Suite (https://github.com/pathscale). http://people.freebsd.org/~jkim/ekopath-devel.tar.bz2 This includes experimental OpenMP support and PathDB. Unfortuntely, PathDB bui

Re: Soliciting opinions on an extension of the bootinfo structure

On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: >> I'm proposing an extension framework for the bootinfo structure used >> to pass information from the bootstrap/loader to the kernel. Although >> I'm only proposing this for the MIPS bootinfo, it's completely >> applicable to any of them. >> >>