On 21.12.2021 15:27, Greg Kroah-Hartman wrote:
On Tue, Dec 21, 2021 at 02:52:05PM +0100, Rafał Miłecki wrote:
How are nvmem devices named?
$ ls /sys/bus/nvmem/devices/
brcm-nvram0
mtd0
mtd1
u-boot-envvar0
So no naming scheme at all.
{sigh}
Example:
$ cat /sys/bus/nvmem/devices/foo/cells/bootcmd
tftp
$ cat /sys/bus/nvmem/devices/foo/cells/bootdelay
5
As you can see above NVMEM cells are not known at compilation time.
Why do you want to expose these in a way that forces the kernel to parse
these key/value pairs? Why not just do it all in userspace like you can
today? What forces the kernel to do it and not a perl script?
So I believe the question is: how can I expose cells in sysfs?
You can do this by dynamically creating the attributes on the fly, but
your show function is going to be rough and it's not going to be simple
to do so. One example will be the code that creates the
/sys/devices/system/machinecheck/machinecheckXX/bank* files.
But I will push back again, why not just do it all in userspace? What
userspace tool is requiring the kernel to do this work for it?
Environment data contains info that may be required by kernel.
For example some home routers store two firmwares on flash. Kernel needs
to read index of currently booted firmware to make sure MTD subsystem
creates partitions correctly.
You are talking about a kernel<->kernel api here, that's not what sysfs
is for at all.
Another example: MAC address. Ethernet subsystem supports reading MAC
from NVMEM cell.
Again, internal kernel api, nothing sysfs is ever involved in.
One could argue those tasks could be handled from userspace but that
would get tricky. Sure - we have API for setting MAC address. However
other cases (like setting active firmware partition and asking MTD to
parse it into subpartitions) would require new user <-> kernel
interfaces.
Ok, but again, sysfs is for userspace to get access to these values.
That's what I'm concerned about. If you want to make an in-kernel api
for other subsystems to get these key/value pairs, wonderful, that has
nothing to do with sysfs.
So I ask again, why do you want to expose these to userspace through
sysfs in a new format from what you have today. Who is going to use
that information and what is it going to be used for.
Sorry, you asked why I need parsing in kernel and I focused on that part
only.
For user space there are also some relevant U-Boot environment entries
(NVMEM cells). Examples: serial number, country code (e.g. WiFi
purposes), default passwords (as printed on labels).
So both: kernel and user space need to access U-Boot environment
variables (NVMEM cells). Each for its own purposes.
Kernel goes first so it needs its own parser of NVMEM content (data).
User space can either: get NVMEM cells exposed by kernel OR parse NVMEM
content on its own. I thought it'd be nice to avoid parsing code
duplication in user space and let kernel expose NVMEM cells.
