> > > Kashyap, > > > Immediately dropping ioctl support will create lots of issues for > > Development/Test (within a org + OEM testing). How about accepting > > updated ioctl patch-set after reviewed-by tag (which will not use > > static MAJOR number) for time being ? > > If we were to introduce an ioctl interface for mpi3mr we would never be able > to deprecate it without breaking existing applications. Martin - Understood that best case scenario is not to have IOCTL interface code at all in kernel tree (for new drivers), but we need this interface to be there for couple of months. As of now, There is only in-house application development happened on <mpi3mr> since product is under development and OEM has access to the h/w for pre-GA testing. We are also planning to document such interface change for those who wants to develop their own application in future. Most of the application which need interopt check of ioctl vs bsg will be Broadcom in-house and we are planning to take care the same. How about providing unlocked_ioctl under module parameter ? By default parameter will be OFF (this will avoid interopt issue as you mentioned) and at least user who really have dependency on Test vehicle for time being can enable it. Once <bsg> interface is available, we will remove whole IOCTL code from tree. Kashyap > > While I appreciate that it is inconvenient to have to update your tooling, this is > the only chance we have to get the interface right. > > -- > Martin K. Petersen Oracle Linux Engineering
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
