My task is to implement a custom layer with fixed names for things like Ethernet and LEDs.
It needs to be the same on x86 and ARM devices. So the Power LED and eth1 is always the same for the applications, but are not connected to the same hardware pins. From my point of view I can do this on ARM with Device Tree assignments. But can I use the device tree on x86 based boards to do this? Is it good practice?
Background Information: Targets: wide range of embedded Linux Boards, Buildsystem: Buildroot, Custom Linux Kernel Versions, no Linux distribution, Busybox running on top
TL;DR - Device tree is not the answer you are looking for. There are many ways to do this depending on your ultimate needs.
Device Tree is inherited from the PowerPC. It is not an interface to user-space. It is intended to provide a data driven customization of board layouts for a given CPU/SOC family. For instance, there are many TI OMAP devicesSee devices in tables each of which has different chips connected to the CPU (different Ethernet MII/RMII,etc) with various pin, clock, power, etc configurations. Each has the same TI OMAP SOC so the code to configure this is know for all of them. Device Tree is an input for the board to configure the SOC to use the hardware. Device drivers may have hooks to alter behaviour when a particular SOC (or board) is found.
Device tree is a way for a boot loader to tell the kernel what hardware is present and should be configured.
There are various methods you can use to talk to user space. Some are the same underlying thing with different use cases...
select (file/socket)Items 3-6 are all basically the same. Generally, files are synchronous. Ie, if you have a PIN output they are fine as you can just write to them from user-space. However, say you have an input pin like a custom card (daughter board) present/insert. Maybe you have some RS-232 cable connected or head-phone insert pin? With a file interface, you must poll them (or you need to have inotify etc support in your kernel code). netlink is a way to provide messages from the kernel to user-space. It makes sense if your pin can be connect to a system interrupt (in any case).
mdev and udev use netlink to tell user-space about PCI, USB, etc hardware being connected/disconnected. You can use a similar scheme for GPIO. You just make a link between /sys/class/output/led1 and /dev/my_company/power_led with a mdev/udev script.
Personally, I would want to put the naming in user space and not the kernel. What is eth1 for instance? Maybe you want a diagnostic and main communication Ethernet port? Hardware might not populate diagnostic port at some point to make the BOM cheaper. Then maybe eth1 is eth0?