Hi Evan,
On 7/18/2018 1:53 AM, Evan Green wrote:
On Mon, Jul 16, 2018 at 5:04 PM Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote:
On Mon, 2018-07-16 at 16:46 -0700, Evan Green wrote:
I see Bart has chimed in on the next series with a suggestion to break
out each field into individual files within configfs. Bart, what are
your feelings about converting to a binary attribute? I remember when
I did my sysfs equivalent of this patch, somebody chimed in indicating
a "commit" file might be needed so that the new configuration could be
written in one fell swoop. One advantage of the binary attribute is
that it writes the configuration atomically.
Hello Evan,
I may be missing some UFS background information. But since a configfs interface
is being added I think the same rule applies as to all Linux kernel user space
interfaces, namely that it should be backwards compatible. Additionally, if
anyone ever will want to use this interface from a shell script, I think that
it will be much easier to write multiple ASCII attributes than a single binary
attribute.
Hi Bart,
I'm unsure about the compatibility aspect for binary attributes that
essentially represent direct windows into hardware. I suppose this
comes down to who this interface is most useful to. Hypothetically
lets say a future revision of UFS adds fields to the configuration
descriptor, but is otherwise backwards compatible. If this interface
is primarily for OEMs initializing their devices in the factory, then
I'd argue they'd want the most direct window to the configuration
descriptor. These folks probably just have a configuration they want
to plunk into the hardware, and would prefer being able to write all
fields over having some sort of compatibility restriction. If, on the
other hand, this is used by long-running scripts that stick around for
years without modification, then yes, it seems like it would be more
important to stay compatible, and have smarts in the kernel to make
writes of old descriptors work in new devices.
At least for myself, I fall into the category of someone who just
needs to plunk a configuration descriptor in once, and would prefer
not to have to submit kernel changes if the descriptor evolves
slightly. It also seemed a little odd that this patch now spends a
bunch of energy converting ASCII into bytes, just to write it without
modification into the hardware, and convert back again to ASCII for
reads.
We plan to use a script for provisioning, and could easily handle
ASCII or rawbytes:
# Some bytes, ready to go with the interface today...
some_bytes="00 01 02 03"
# Same bytes, now in binary format
bytes_fmt=$(echo " $some_bytes" | sed 's/ /\\x/g')
/usr/bin/printf "$bytes_fmt" > /configfs/ufs_provision
I'm not dead set on binary, since as above I could do it either way,
but it seemed worth at least talking through. Let me know what you
think.
-Evan
I am using ASCII format for reading/writing to config desc as it will be
more readable for users and easier/comfortable to compare any value to
default spec value(if required).
So I don't really see any harm in using current ASCII format for
provisioning purpose.
-Sayali
