From: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
Date: Thu, 22 Feb 2018 13:04:41 +0100 [thread overview]
Message-ID: <4dcaa501-233c-0b61-bff6-a86ae84b320b@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAKTCnzkjbNVxBVTKmffbxsyqMb83y2tXN1Xv4Zm3VT+sxePdpg@mail.gmail.com>
>>> Yeah, I think metadata will evolve for a while till it settle's down.
>>> Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program
>>> calling an older kernel will never work, since the size of that
>>> struct
>>> will always be larger than what the OS supports and our
>>> copy_to_user()
>>> will fail. The other option is for the user program to try all
>>> possible versions till one succeeds, that is bad as well. I think
>>> there are a few ways around it, if we care about this combination.
>>>
>>> Balbir Singh.
>>>
>>
>> We have a number of reserved members at the end of the struct which can
>> be re-purposed for future information (with a corresponding bump of the
>> version number).
>
> Good point, agreed
I initially had reservations about using an ioctl command for various
AFU/context parameters because extensibility is going to be a pain. With
the current reserved fields and versioning, we're ok for some time
(version handling will remain a bit of a pain but that's life). I agree
it helps the library by making things more light weight compared to
sysfs. But if we need to add parameters in the future, we should keep
sysfs as an option, especially if it's for rarely used parameters, i.e.
not something we'll need immediately after an open().
Fred
next prev parent reply other threads:[~2018-02-22 12:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 4:57 [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace Alastair D'Silva
2018-02-21 5:49 ` Andrew Donnellan
2018-02-21 6:43 ` Balbir Singh
2018-02-21 11:25 ` Frederic Barrat
2018-02-21 23:37 ` Alastair D'Silva
2018-02-22 3:46 ` Balbir Singh
2018-02-22 3:51 ` Alastair D'Silva
2018-02-22 5:32 ` Balbir Singh
2018-02-22 12:04 ` Frederic Barrat [this message]
2018-02-21 23:32 ` Alastair D'Silva
2018-02-22 3:19 ` Michael Ellerman
2018-02-22 3:41 ` Balbir Singh
2018-02-22 3:47 ` Andrew Donnellan
2018-02-22 3:48 ` Alastair D'Silva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4dcaa501-233c-0b61-bff6-a86ae84b320b@linux.vnet.ibm.com \
--to=fbarrat@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).