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 ?
>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. >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 >> >>
