RE: [PATCH 2/7] miscdevice: adding support for MPI3MR_MINOR(243)

[Kashyap Desai <kashyap.desai@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

>
>
> 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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 bytes --]