The kernel should not in any case have knowledge about directories or
subdirectories where the firmware files are stored. That is fully
irrelevant for the kernel.
Exactly my point! Hence, the kernel just gives it an arbitrary name. The
fact that userspace uses this as a filename could be regarded as a bug,
but it works fine. Therefore, the kernel simply assigns an arbitrary,
NULL-terminated string as the name. It happens to include a / because it
is convenient with the current userspace implementation, but that's mere
detail, the ABI/API here is to allow any arbitrary names.
Especially with the case of built-in firmwares now, it because more
important to do it right. The one reason why we have to handover the
struct device to request_firmware() is that we can give the helper
script full access to the device and driver information of the caller.
Hence adding for example b43/ as prefix simply duplicates everything
since the struct device has a link to the driver that is requesting a
firmware file.
But that doesn't matter at all! Dave's work to build firmware files into
the kernel will simply result in an entry in the kernel firmware table
that has a '.name = "b43/pcm5.fw"', nothing needs to know that b43 is a
module name, in fact, it could very well be 'broadcom wlan/pcm5.fw' as
well.
That is not what I am proposing. What I am proposing is that we do
this the right way. Meaning that we fix udev to do the namespacing. I
am working on a way to have this change in a backward compatible way.
That will introduce a "flag-day" where you have to upgrade userspace
with the kernel, and vice versa, OR userspace will have to guess. Not a
good solution either.
Why are you so fixated on special-casing the single character '/'?