Re: the cost of EXPORT_SYMBOL_GPL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux