From owner-freebsd-arch@FreeBSD.ORG Thu Sep 8 22:10:42 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39242106566B for ; Thu, 8 Sep 2011 22:10:42 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by mx1.freebsd.org (Postfix) with ESMTP id CD6978FC0A for ; Thu, 8 Sep 2011 22:10:41 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTmk9YTYIG7xPIZ0CYaoZqG2qNZU+7/K8@postini.com; Thu, 08 Sep 2011 15:10:41 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 8 Sep 2011 14:55:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 8 Sep 2011 17:55:04 -0400 From: Andrew Duane To: "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" Date: Thu, 8 Sep 2011 17:55:02 -0400 Thread-Topic: Soliciting opinions on an extension of the bootinfo structure Thread-Index: AQHMbnH2giQRxi0m50uyS6Evz0JaPw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: Soliciting opinions on an extension of the bootinfo structure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 22:10:42 -0000 I'm proposing an extension framework for the bootinfo structure used to pas= s information from the bootstrap/loader to the kernel. Although I'm only pr= oposing this for the MIPS bootinfo, it's completely applicable to any of th= em. 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_pext bi_pext; /* platform extensions if d= efined */ +#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) h= eader file in your source, and you have whatever extensions you want, witho= ut affecting other platforms, architectures, families, or developers. The f= ile 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_MAGIC 0xCADECADE +#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 aduane@juniper.net Westford, MA 01886-3418