Freeman.Liu at Sun.COM wrote: > Edward Pilatowicz wrote: > >> [ sigh. resending with correct cc. ] >> >> so i have a few comments that mainly pertain to the documentation >> of this functionality for driver writers. >> >> the first is that since firmware will be deilvered wrapped in elf >> files, on x86 systems driver writers should deliver two copies >> of their firmware, one as a 32-bit elf file and the other as a 64-bit >> elf file. this should be explicity mentioned in the documentation. >> >> > Yes. That's right. And James, how can I add that information into the > proposal ?
You can revise the proposal (while saving the original some simple convention *.orig), and when you sense convergence, provide the diff to all for a final round of consensus. This item is not contraversial and you should not expect problems. > >> my second comment is that while i realize that one of the boundary >> conditions of this case is: >> >> This proposal does not provide ways to avoid name conflict >> between the firmware image module. The module provider should >> name it reasonably to avoid that. >> >> i still think that this case should provide advice for naming firmware >> files to driver writers. of example, should we create a firmware >> directory for all firware files? or should firmware files have the >> same name as the dirver but with some special extension? >> >> > It will be good if we can work out universal naming scheme for all > these firmware modules (or even all > the modules). But I dont think we are experienced enough to make it. > I prefer leaving it to driver writers now > and picking it up when we get more experiences here. I would suggest that you take some leadership to avoid potential name space pollution that is hard to undo later. The suggestion of using driver name as prefix with special _extension is quite reasonable. I like the idea. We are counting on the disambiguating power of driver name, and that's a good start. You can recommend the use of of version/date/descriptive word to driver writers to manage their own name space as they see fit. > >> lastly, until new boot on sparc integrates, there is no public way for >> boot devices on sparc to access firmware files. the documentation >> should probably mention this limitation. >> >> > For ddi_modopen, it is correct. However, you can make the driver > depend on the firmware module and > the krtld will handle it. > > Thank you > --Freeman > >> ed >> >> On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote: >> >> >>> I'm sponsoring this fast-track request for Freeman Liu. The timer is >>> set to 06/22/2007. (A brief summary: 2005/050 interfaces are now >>> Committed, patch/micro release binding.) >>> >>> >>> Background >>> >>> Many hardware devices contain some software to function correctly. >>> Traditionally, this piece of software was stored in non-volatile >>> storage and thus called firmware. But recently, more and more >>> hardware vendors replaced the non-volatile memory with volatile >>> one to lower cost. For example, Intel 3945 wifi card and Intel >>> wusb devices. And the "firmware", which comes in the form >>> of an image file, now needs to be downloaded into the hardware >>> before the hardware can fully function. >>> >>> Most of other main-stream OSes provide interfaces to access >>> firmware >>> in raw-data format. But the shortage of the raw-data format is that >>> authentication check is not available. Therefore, we prefer to wrap >>> the raw-data format firmware image in a kernel module so that we >>> can >>> sign and verify it by elfsign. >>> >>> In Solaris, the existing interfaces ddi_modopen, ddi_modsym and >>> ddi_modclose serve this purpose very well. These interfaces have >>> been >>> used inside Sun for several cases including md, kcf and brandZ >>> and are >>> mature. However, these interfaces are private ones and can not be >>> leveraged by hardware vendors and communities. >>> >>> This proposal is a follow up to "ddi_modopen dynamically >>> access a loadable kernel module" (PSARC 2005/050). It is >>> necessary to becoming familiar with that case to understand >>> this issue. >>> >>> Competitive Analysis >>> >>> Windows provides interfaces to load firmware and sign at the >>> package >>> level. Windows requires all kernel components signed for the 64-bit >>> platform. A signature can be stored in the .cat file of a package >>> which contains the checksum of selected files in the packages. >>> >>> Linux adopts similar solution. For example, rpm provides signature >>> function. >>> >>> Proposal >>> >>> We propose to make the interfaces ddi_modopen, ddi_modclose and >>> ddi_modsym in 2005/050 Committed. >>> >>> We will use these interfaces to deliver separate firmware files on >>> Solaris, and encourage other developers to use the interfaces in >>> this >>> way as well. >>> >>> Compared to other solutions, this proposal has many advantages. >>> First, it can enable drivers to load and unload the image >>> dynamically. >>> This avoids unnecessary waste of ram. Second, because dependency >>> can >>> be set between drivers and the firmware image module, the >>> potential boot >>> device can rely on this to load firmware. Third, it can signed to >>> ensure the authentication. >>> >>> This proposal requires a patch release binding so that it can be >>> backported to S10 updates. But it will not be back ported to S9 >>> and earlier version for the same reason mentioned in 2005/050 that >>> doing that requires many of the module loading bugs fixed in s10 >>> to be back ported too. >>> >>> Interfaces >>> >>> ------------------------------------------------------------------ >>> Interface Name Stability Comments >>> ------------------------------------------------------------------ >>> >>> KRTLD_MODE_FIRST Commited Mode argument to >>> ddi_modopen(9F). >>> >>> ddi_modhandle_t Commited Opaque handle returned >>> by ddi_modopen(9F). >>> >>> ddi_modopen(9F) Commited Peer of dlopen(3C) >>> >>> ddi_modsym(9F) Commited Peer of dlsym(3C) >>> >>> ddi_modclose(9F) Commited Peer of dlclose(3C) >>> >>> Prototypes (defined in modctl.h) >>> >>> #define KRTLD_MODE_FIRST 0x0001 >>> >>> typedef struct __ddi_modhandle *ddi_modhandle_t; >>> >>> extern ddi_modhandle_t ddi_modopen(const char *modname, >>> int mode, int *errnop); >>> >>> extern void *ddi_modsym(ddi_modhandle_t handle, >>> const char *symname, int *errnop); >>> >>> extern int ddi_modclose(ddi_modhandle_t handle); >>> >>> #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose) >>> >>> Documentation >>> Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added. >>> >>> A section about "Dynamic module access functions" will be added to >>> Appendix B of "Writing Device Drivers". >>> >>> The dynamic way to fulfill the dependency of modules will be >>> added to >>> the section "Module dependencies" of Chapter 20 of "Writing Device >>> Drivers". >>> >>> Boundary Condition >>> This proposal does not cover the case to upgrade firmware in >>> non-volatile memory, such as flash. That always needs to stop >>> the hardware and the upgrade process is usually done by a program >>> provided by vendor. >>> >>> This proposal does not provide ways to avoid name conflict >>> between the firmware image module. The module provider should >>> name it reasonably to avoid that. >>> >>> This proposal does not cover the case to load raw-data format >>> firmware. >>> >>> Reference >>> http://sac.sfbay/PSARC/2005/050/ >>> RPM manpage: http://www.netadmintools.com/html/8rpm.man.html >>> (Windows) Code Signing Best Practices: >>> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc >>> >>> >>> >> > -- Tzongyu Paul Lee, Tzongyu.Lee at Sun.Com or Paul.Lee at Sun.COM BJS05 7225, x84343
