Yes. I agree that we are unlikely to get this right. I still feel that pushing the uscsi ioctl and asking userland to sort this mess out is an inferior approach and that this also means that it guarantees that nobody will be able to use this work for anything other than scsi drives. That makes me sad.
That said this is my architectural feeling. We don't have PSARC anymore and I can't force an implementation. You did ask for discussion and opinions though. My opinion is still that I'd rather see you invent a custom ioctl to deliver firmware in one ioctl to sd (can be sd specific) and then hide the rest of the details from userland. This would make it easier to extend this work to other devices (nvme is specifically interesting here) with less effort and promote code reuse and simplification in the userland bits. I also think it will actually be less effort to develop and review such an implementation. But maybe you feel otherwise. Btw there is also a safety thing here. I believe flashing should appear to be an atomic operation (synthetic via lock) to userland, and that it may be important to ensure that block activity is not present while flashing is taking place. I think it's a lot easier to get that right behind a single ioctl than if you just use USCSI. Sent from my iPhone > On Apr 26, 2016, at 7:28 AM, Robert Mustacchi <[email protected]> wrote: > >> On 4/25/16 21:16 , Garrett D'Amore wrote: >> Indeed, actually it would be *vastly* nicer to have an ioctl that could be >> cleanly implemented by other devices that are storage-like, but don’t >> implement true SCSI. For example, the NVME driver based on blkdev — it >> wouldn’t be hard to add a new ioctl that was clean to blkdev, but I’m >> *vehemently* opposed to teaching blkdev SCSI. > > I feel like you've somehow misunderstood the intent of this. We're not > going to be teaching blkdev SCSI or trying to transform a firmware > upgrade for say a NIC or BMC and turn it into some kind of SCSI-like > thing. Nothing that we're doing is trying to jam SCSI into something > that isn't SCSI, unless you consider SAS devices for some reason in the > not-SCSI department. > > As I mentioned previously, as we work with other devices, we'll start > figuring out what that interface *should* be. However, it's a bit fool > hardy to presume we're going to get this right without thinking through > all of the different kinds of devices out there and starting to > understand what it's like for devices which don't have a simple upgrade > path. Some may have more than one piece of firmware. You may need to > break up the downloading and activation because of deferred bits. You > need different ways to have every device opt into things. How do you > describe the read-only eeprom vs. a second writeable one on say a NIC > and make sure that both are discoverable and downloadable to the user? > > These are all important questions, but honestly, ones we don't have the > luxury to answer while we have customers burning in the field from > drives that need their firmware upgraded due to bad vendor bugs and > can't afford the down time to do other vendor-based upgrades. If we were > writing all of this from scratch, I'd feel differently, but most of this > logic already exists in the system. > > Also, from doing other firmware upgrades in past lives, even though we > have the max transfer side issue for uscsi (which still exists in the > kernel and is going to look exactly the same regardless of whether it's > driven in userland or the kernel), some firmware upgrades may actually > be better driven from userland where it's simpler to iterate, upgrade, > and deliver. Quite a bit of the firmware upgrade work that we did with > Fishworks was driven in userland. The key is to make sure that as we add > support for *new* devices that we make sure to design and architect that > correctly. I don't know enough to say beyond a doubt that it's the > superior decision to jam 100% into the kernel with no room for negotiation. > > Just to make sure it's clear (at the risk of being repetitive), as it > didn't seem that way from your mail, no one is trying to make things > that aren't actual SCSI/SAS devices actually use a SCSI/SAS firmware > upgrade framework. This is part of the importance of fwflash being > pluggable, so we can better experiment and use different methods for > different devices as we work through and determine what the right way is > to have this look like a broad swath of devices. This, I thought, was > what you were getting at in your comments on the original PSARC case for > pluggable fwflash and your desire to use it with PRISM wifi devices. > > Robert > >>> On Mon, Apr 25, 2016 at 4:02 PM, Joshua M. Clulow <[email protected]> wrote: >>> >>>> On 25 April 2016 at 15:58, Garrett D'Amore <[email protected]> wrote: >>>> 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. >>> >>> Why is this an abuse of the uscsi ioctl? What is it _for_, if not >>> sending SCSI commands to targets from outside the kernel? >>> >>> -- >>> Joshua M. Clulow >>> UNIX Admin/Developer >>> http://blog.sysmgr.org > > ------------------------------------------- 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
