RE: Soliciting opinions on an extension of the bootinfo structure
Since this has turned out to be a more contentious idea than I thought, and the upcoming FDT work will probably remove the need for it at all, I'm withdrawing the idea. Although our current code uses such a platform extension structure, we can make do with either metadata or environment variables for the time being. ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Friday, September 09, 2011 8:32 AM To: freebsd-a...@freebsd.org Cc: Peter Wemm; Peter Grehan; freebsd-hackers@freebsd.org; Andrew Duane Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote: On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan gre...@freebsd.org 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. That doesn't stop you from adding metadata to the kernel. It is just an array of variable length blobs appended after 'end'. Any boot loader can support adding metadata. -- John Baldwin ___ 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
That's correct. This is actually part of a larger effort to open up the MIPS code to a range of new bootstraps. Some bootstraps use the bootinfo facility extensively. It's an easy way to pass some simple information to the kernel without the clutter of metadata and other such things. ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: Peter Wemm [mailto:pe...@wemm.org] Sent: Thursday, September 08, 2011 6:48 PM To: Peter Grehan Cc: Andrew Duane; freebsd-hackers@freebsd.org; freebsd-a...@freebsd.org Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan gre...@freebsd.org 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
Re: Soliciting opinions on an extension of the bootinfo structure
On Thursday, September 08, 2011 6:25:23 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). I agree. The metadata appended to the end of the kernel is a better way to manage this. -- John Baldwin ___ 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 Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote: On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan gre...@freebsd.org 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. That doesn't stop you from adding metadata to the kernel. It is just an array of variable length blobs appended after 'end'. Any boot loader can support adding metadata. -- John Baldwin ___ 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
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: Soliciting opinions on an extension of the bootinfo structure
On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan gre...@freebsd.org 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
