lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <feb8ee5fcd765e0618a27e4fa5fe5c2a@codeaurora.org>
Date:   Wed, 28 Sep 2016 16:04:02 -0700
From:   subhashj@...eaurora.org
To:     Joao Pinto <Joao.Pinto@...opsys.com>
Cc:     Kiwoong Kim <kwmad.kim@...sung.com>,
        'Shaun Tancheff' <shaun.tancheff@...gate.com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-scsi-owner@...r.kernel.org
Subject: Re: UFS API in the kernel

On 2016-09-28 02:19, Joao Pinto wrote:
> Hi again!
> Could you also send me an example of how you are using the IOCTL from 
> your user
> app (send/receive data)? I already have my implemented but you use a 
> different
> mechanism (I have checked your structures in uapi/scsi/ufs/) and I have 
> to port
> it! Thanks!

You may use the SG_IO ioctl with sg device node for any data read/write 
operations.
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io.html has some 
details.

> 
> 
> On 9/28/2016 10:06 AM, Joao Pinto wrote:
>> 
>> Hi Subhash,
>> 
>> On 9/28/2016 12:05 AM, subhashj@...eaurora.org wrote:
>>> Hi Joao,
>>> 
>>> 
>>> On 2016-09-26 18:10, Kiwoong Kim wrote:
>>>> Hi.
>>>> 
>>>> If you want to declare some things for user interface,
>>>> is it be better to put those thing include/uapi/linux/ than 
>>>> include/linux?
>>>> 
>>>> Agreed with Mr. Pinto's opinion with respect to implementing 
>>>> additional ioctls.
>>> 
>>> Yes, "scsi_host_template" allows the LLD's to export their ioctl 
>>> callback and
>>> then you can use the sg interface to issue UFS specific ioctls. We 
>>> had
>>> implemented similar ioctl for our use, here is the reference code:
>>> https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/scsi/ufs/ufshcd.c?h=LA.HB.1.1.1.c2#n6791.
>>> This was mainly done to  export the UFS query request interface to 
>>> user space.
>>> Declarations where exported under include/uapi/scsi/ufs/ . If you 
>>> want to build
>>> upon this already existing functionality, i can post the formal patch 
>>> on mailing
>>> list.
>> 
>> Yes, of course I have interest on building on top of what you have 
>> done already.
>> Did yu submit this patch to the kernel already? Could you please send 
>> me the
>> patch and kernel version to apply?
>> 
>> Thanks,
>> Joao
>> 
>>> 
>>> Regards,
>>> Subhash
>>> 
>>> 
>>>> 
>>>> Regards.
>>>> 
>>>>> -----Original Message-----
>>>>> From: linux-scsi-owner@...r.kernel.org [mailto:linux-scsi-
>>>>> owner@...r.kernel.org] On Behalf Of Shaun Tancheff
>>>>> Sent: Tuesday, September 27, 2016 4:23 AM
>>>>> To: Joao Pinto
>>>>> Cc: linux-scsi@...r.kernel.org; linux-kernel@...r.kernel.org
>>>>> Subject: Re: UFS API in the kernel
>>>>> 
>>>>> On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto 
>>>>> <Joao.Pinto@...opsys.com>
>>>>> wrote:
>>>>>> Hi!
>>>>>> 
>>>>>> I am designing an application that has the goal to be an utility 
>>>>>> for
>>>>>> Unipro and UFS testing purposes. This application is going to run 
>>>>>> on
>>>>>> top of a recent Linux Kernel containing the new UFS stack 
>>>>>> (including the
>>>>> new DWC drivers).
>>>>>> 
>>>>>> I am considering doing the following:
>>>>>> a) Create a new config item called CONFIG_UFS_CHARDEV which is 
>>>>>> going
>>>>>> to create a char device responsible to make some IOCTL available 
>>>>>> for
>>>>>> user-space applications
>>>>>> b) Create a linux/ufs.h header file that contains data structures
>>>>>> declarations that will be needed in user-space applications
>>>>> 
>>>>> I am not very familiar with UFS devices, that said you should have 
>>>>> an sgX
>>>>> chardev being created already so you can handle SG_IO requests.
>>>>> There also appear to be some sysfs entries being created.
>>>>> 
>>>>> So between sg and sysfs you should be able to handle any user-space 
>>>>> out of
>>>>> band requests without resorting to making a new chardev.
>>>>> 
>>>>> Adding more sysfs entries, if you need them, should be fine.
>>>>> 
>>>>> You may find it easier to expand on the existing interfaces than to 
>>>>> get
>>>>> consensus on a new driver and ioctls.
>>>>> 
>>>>> Hope this helps,
>>>>> Shaun
>>>>> 
>>>>>> Could you please advise me about what the correct approach should 
>>>>>> be
>>>>>> to make it as standard as possible and usable in the future?
>>>>>> 
>>>>>> Thank you very much for your help!
>>>>>> 
>>>>>> regards,
>>>>>> Joao
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>>>> linux-scsi"
>>>>>> in the body of a message to majordomo@...r.kernel.org More 
>>>>>> majordomo
>>>>>> info at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma
>>>>>> jordomo-2Dinfo.html&d=DQICaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=Wg5NqlNlVTT7Ug
>>>>>> l8V50qIHLe856QW0qfG3WVYGOrWzA&m=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY
>>>>>> u88nM&s=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc&e=
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Shaun Tancheff
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>>> linux-scsi" in
>>>>> the body of a message to majordomo@...r.kernel.org More majordomo 
>>>>> info at
>>>>> http://vger.kernel.org/majordomo-info.html
>>>> 
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>> linux-scsi" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ