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 other bare-metal stuff. There're also packages for this. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpAZTDGsBtJJ.pgp Description: PGP signature
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 incorrect, in this case please > correct me. > > > -any server software > Yes, server software is a good candidate for bringing cap.mode in. Though > this applies to servers that do not include in-process support for > interpreters (ie Apache + mod_php), see later why. Such software as nginx, > lighttpd is OK. Speaking about base system components, this list includes > inetd daemons (but modification of inetd itself is NOT sufficient and > ineffective, capability support implies modifying code of daemons) I would also suggest our Heimdal Kerberos implementation as it performs a lot of non-trivial ASN.1 and GSSAPI decapsulation/encapsulation when processing packets and we saw a lot of vulenrabilities in the past in these areas. Unfortunately, Heimdal will be probably to large to break into compartments. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 I do? > > -- > // Black Lion AKA Lev Serebryakov > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 notifications about network cable plug/unplug, which doesn't look like something bus-related. -- // Black Lion AKA Lev Serebryakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 bad. It is simply how things are done. > Why devctl_notify() is bound to bus, anyway? It is used, for > example, for notifications about network cable plug/unplug, which > doesn't look like something bus-related. If you look at it you'll see that bus.h covers a range of areas, general device instantiation being one of them. > > -- > // Black Lion AKA Lev Serebryakov > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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:
bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT
struct bootinfo {
u_int32_t bi_kernend; /* end of kernel space */
u_int32_t bi_envp;/* environment */
u_int32_t bi_modulep; /* preloaded modules */
+#ifdef BOOTINFO_PEXT
+ struct bootinfo_pextbi_pext;/* platform extensions if
defined */
+#endif
};
Then, any vendor, platform, architecture, family, or developer could define a
new header file (or expand an existing one) with a definition of struct
bootinfo_pext, and a #define BOOTINFO_PEXT. Include the new (or existing)
header file in your source, and you have whatever extensions you want, without
affecting other platforms, architectures, families, or developers. The file
we're looking to add is sys/mips/cavium/bootinfo_octeon.h:
+/*
+ * Platform bootinfo extensions for OCTEON bootinfo structure
+ *
+ * Specific vendors can add their own bootinfo_pext structures
+ * surrounded by #ifdef OCTEON_VENDOR_XXX
+ */
+
+#include "opt_cvmx.h" /* For OCTEON_VENDOR_XXX definitions */
+
+#ifdef OCTEON_VENDOR_JUNIPER
+#define BOOTINFO_PEXT /* include bootinfo_pext in main structure */
+#define BOOTINFO_PEXT_MAGIC0xCADECADE
+#define BOOTINFO_PEXT_VERSION 1
+
+struct bootinfo_pext {
+int pext_i2cid;
+u_int32_t pext_flags;
+u_int32_t pext_magic; /* Magic number for octeon
pext */
+u_int32_t pext_version; /* Version of pext */
+u_int16_t pext_uboot_major_rev;
+u_int16_t pext_uboot_minor_rev;
+u_int16_t pext_loader_major_rev;
+u_int16_t pext_loader_minor_rev;
+};
+#endif /* OCTEON_VENDOR_JUNIPER */
Reasonable? Unreasonable? Insane?
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net Westford, MA 01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 options are turned off by default for now. Although it seems working fine for many non-trivial C/C++/Fortran sources, please do not use it for any serious project because I have seen few internal compiler errors and crashes. Be aware of ugly hacks! ;-) I just wanted to share it now because it was on the WantedPorts list on Wiki for a while. If anyone with more clues want to pick it up from here, please feel free. Cheers, Jung-uk Kim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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: bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT Any reason not to put the vendor bits into another piece of loader metadata ? That seems the extensible way to add additional info from the loader, rather than extending bootinfo (as was the case pre-loader days). later, Peter. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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 builds fine but just crashes ATM. Both options are turned off by default for now. Although it seems working fine for many non-trivial C/C++/Fortran sources, please do not use it for any serious project because I have seen few internal compiler errors and crashes. Be aware of ugly hacks! ;-) I just wanted to share it now because it was on the WantedPorts list on Wiki for a while. If anyone with more clues want to pick it up from here, please feel free. Would it be possible to work with upstream on the changes you've made? If you do a github pull request we should be able to review/comment/merge any changes back upstream efficiently. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
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. >> >> What I propose is adding an optional platform extension structure: >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > Any reason not to put the vendor bits into another piece of loader metadata > ? That seems the extensible way to add additional info from the loader, > rather than extending bootinfo (as was the case pre-loader days). > > later, It sounds like they're not using loader, which is probably a reasonable thing for their environment. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
