the cost of EXPORT_SYMBOL_GPL
Greg KH
greg at kroah.com
Wed Jun 17 11:08:04 EDT 2020
On Wed, Jun 17, 2020 at 04:26:49PM +0200, Tomek The Messenger wrote:
> > If we have one unique sysfs interface then it is easier for
> > everyone: tester, developer to proceed with such device, testing or
> > debugging.
>
> >>No - not really. Because if you're mapping 3 or 4 SOC resets reasons to
> >>one thing, you then have to write code that says "If it's SoC 1, then
> >>a bit 12 being set was a memory error, but if it's SOC 2 bit 12 means a
> >>PCI bus reset and a memory parity error is bit 17, but a memory ECC
> >>error is bit 4."
>
> >>And if the meaning of the reset register is different, a lot of *other*
> things
> >>are probably different too, which is an argument for just having separate
> >>drivers for each SoC.
>
> Yes separate drivers but the actions do by them is to create the same files
> in sysfs. So if somebody use intel, texas instrument or xilinx soc then in
> order to read reset reason or other stuff he will use sysfs. So this will
> look likes:
> /sys/resetreg - 3 separate drivers plus one core driver where there is
> common part
> /sys/otherfunctionality- as Above
> Apart from above 3 drivers where there is api to access registers from
> ti, Intel, xilinx. This was original question if place here all api
> reads/writes or only common between sysfs kernel modules.
> ...
> /sys/functionalityN -> separate driver for intel, TI, Xilinx
Again, use the specific subsystem for these values, don't try to expose
your own mess in sysfs, especially with "raw" kobjects. You will run
into loads of problems that way.
greg k-h
More information about the Kernelnewbies
mailing list