On Thu, Feb 20, 2025 at 04:21:37PM +0200, Matti Vaittinen wrote: > On 20/02/2025 16:04, Andy Shevchenko wrote: > > On Thu, Feb 20, 2025 at 03:40:30PM +0200, Matti Vaittinen wrote: > > > On 20/02/2025 14:41, Andy Shevchenko wrote: > > > > On Thu, Feb 20, 2025 at 09:13:00AM +0200, Matti Vaittinen wrote: > > > > > On 19/02/2025 22:41, Andy Shevchenko wrote: > > > > > > On Wed, Feb 19, 2025 at 02:30:27PM +0200, Matti Vaittinen wrote: ... > > > > > > > +EXPORT_SYMBOL_GPL(iio_adc_device_num_channels); > > > > > > > > > > > > No namespace? > > > > > > > > > > I was considering also this. The IIO core functions don't belong into a > > > > > namespace - so I followed the convention to keep these similar to other IIO > > > > > core stuff. > > > > > > > > But it's historically. We have already started using namespaces > > > > in the parts of IIO, haven't we? > > > > > > Yes. But as I wrote, I don't think adding new namespaces for every helper > > > file with a function or two exported will scale. We either need something > > > common for IIO (or IIO "subsystems" like "adc", "accel", "light", ... ), or > > > then we just keep these small helpers same as most of the IIO core. > > > > It can be still pushed to IIO_CORE namespace. Do you see an issue with that? > > No. I've missed the fact we have IIO_CORE O_o. Thanks for pointing it out! > > > Or a new opaque namespace for the mentioned cases, something like IIO_HELPERS. > > I am unsure if it really benefits to split this out of the IIO_CORE. I've a > feeling it falls into the category of making things harder for user with no > apparent reason. But yes, the IIO_CORE makes sense. Probably I was not clear, I mean to put this under a given namespace. There is no a such, we have currently: IIO_BACKEND IIO_DMA_BUFFER IIO_DMAENGINE_BUFFER IIO_GTS_HELPER IIO_RESCALE > > > > > (Sometimes I have a feeling that the trend today is to try make things > > > > > intentionally difficult in the name of the safety. Like, "more difficult I > > > > > make this, more experience points I gain in the name of the safety".) > > > > > > > > > > Well, I suppose I could add a namespace for these functions - if this > > > > > approach stays - but I'd really prefer having all IIO core stuff in some > > > > > global IIO namespace and not to have dozens of fine-grained namespaces for > > > > > an IIO driver to use... ... > > > foo &= (~bar); > > > > > > is _much_ faster than seeing: > > > > Strongly disagree. One need to parse an additional pair of parentheses, > > and especially when it's a big statement inside with nested ones along > > with understanding what the heck is going on that you need them in the > > first place. > > > > On top of that, we have a common practices in the LK project and > > with our history of communication it seems you are trying to do differently > > from time to time. Sounds like a rebellion to me :-) > > I only rebel when I (in my opinion) have a solid reason :) > > > > foo &= ~bar; > > > > > > and having to google the priorities. > > > > Again, this is something a (regular) kernel developer keeps refreshed. > > Or even wider, C-language developer. > > Ha. As I mentioned, I've been writing C on a daily bases for almost 25 > years. I wonder if you intent to say I am not a kernel/C-language developer? > Bold claim. I'm just surprised by seeing that style from a 25y experienced C developer, that's all. -- With Best Regards, Andy Shevchenko
