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
