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
