Sure Robert. Still, even if we wind up *not* doing a common framework, I’d rather see an ioctl to deal with this than abusing the uscsi ioctl. Even an sd-specific ioctl would be superior to USCSI, IMO, and this could be a stepping stone to a more neutral common implementation in the future.
On Mon, Apr 25, 2016 at 3:26 PM, Robert Mustacchi <[email protected]> wrote: > Hi Garrett, > > Thanks for the feedback. This is something I've thought about before. > Particularly when I was dealing with the world of eeproms on devices > like ixgbe and the like. I've also been trying to think through what > firmware upgrade would look like in the world of i40e. > > Unfortunately, over the years I lost notes on what that sketch looked > like, but it had many things that weren't dissimilar to what you > described below. In particular, the main focus of what I was doing was > for permanent firmware upgrade as opposed to the device needing firmware > at power on. I think the latter case has actually been discussed and > solved in work that Hans did and is merely waiting for the consumer to > be cleaned up and finished before both are integrated. > > One thing though is that interface is going to need to be pretty well > thought out and we're going to need to make sure that a rather diverse > set of consumers are considered here. So I'm going to make some notes > about this in the rfd in the future work direction as at this time I'm > not in a position where I'll be working on firmware upgrade for all > kinds of different devices. It's my hope that as we continue to explore > the questions of firmware upgrade and looking at it more seriously for > other devices, we'll start to get a better idea of what this looks like > and what makes sense. > > Thanks for taking a look and the feedback. > > Robert > > On 4/25/16 11:53 , Garrett D'Amore wrote: > > The write up of the partial DMA is cogent and correct. > > > > However, I am of the opining that there is a unique opportunity here to > > express something another way than via USCSI, which I happen to think is > a > > hideous way to deal with this. USCSI is a sort of catch all for “any > > other SCSI command we don’t know how to handle”, and IMO we can do much > > better here. I’d really like to avoid the mistake of continuing to > abuse > > USCSI this way. > > > > So what I’d actually like to see instead is a new firmware flash API > > (ioctl-based) defined, ideally that a common framework could use, > > essentially presenting firmware flashing as a first class operation. > Then > > the sd(7d) driver could internally use whatever mechanism(s) it finds are > > best for supporting this. For example, I imagine that I’d implement > this a > > single transfer between user and kernel space, then use either multiple > > mode 7 steps, or a single mode 5 step, depending on the device’s > behavior . > > User space application code (the fwflash utility) need not be bothered > with > > any of this. > > > > I believe some other open source operating systems have generalized > > firmware loading interfaces. Part of figuring out a good interface here > > is coming up with a solution to “permanent” firmware rewrite, vs. a > device > > that needs a firmware file to be loaded into device RAM during boot (see > > linux’s request_firmware() interface for examples of this). > > > > If you look at fwflash, it has some pretty basic operations, so it should > > be straight-forward to map these into an ioctl API, IMO. > > > > Actually, even better, one could imagine a central “fwflash” driver that > > individual device nodes “register” a fwflash ops vector to, so that in > the > > future it would not be necessary to write new fwflash plugins for a > driver, > > but instead just supply an fwflash ops entry point and register it. The > > fwflash module/API would express the flash operations via ioctl to > fwflash. > > > > On Mon, Apr 25, 2016 at 10:21 AM, Robert Mustacchi <[email protected]> > wrote: > > > >> Hi, > >> > >> This RFD focuses on changes to illumos to better enable firmware > >> upgrade. It mostly focuses on extending some public and private > >> interfaces for use with the fwflash(1M) command which can be used to > >> flash disk drive firmware. > >> > >> https://github.com/joyent/rfd/tree/master/rfd/0031 > >> > >> Feedback is appreciated. > >> > >> Robert > >> > > > > > > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
