setting driver properties for a particular device

[Ian Lepore]

On Wed, 2019-06-05 at 16:21 +0300, Andriy Gapon wrote:
> On 30/05/2019 00:40, Ian Lepore wrote:
> > On Wed, 2019-05-29 at 13:31 +0300, Andriy Gapon wrote:
> > > On 29/05/2019 13:29, Michael Zhilin wrote:
> > > > Hi,
> > > > 
> > > > There are kenv and sysctl. Is it far from what you are looking for?
> > > 
> > > No.  When I said programmatically, I meant programmatically from
> > > within the kernel.
> > > 
> > 
> > Hmmm.  Whatever you do, it's going to amount to a conspiracy of
> > agreement between the driver that wants to set this info and the driver
> > that is expected to act on it.  So if you don't use the existing hints
> > mechanism, then you'll have to invent something new, and the gpioled
> > driver will have to be updated to also check that new mechanism to see
> > if there is any config info there that affects it.  I'm not sure that's
> > a big win over the slight inelegance of crafting a hint string at
> > runtime.
> 
> I think you are right.
> Probably, I am going to add a helper function to make that job easier.
> E.g., something like
>   set_dev_hint(device_t dev, const char *name, const char *val);
> or perhaps
>   set_dev_hint(device_t dev, const char *name, const char *fmt, ...);

I like the second one.  I think it will be pretty likely that the hints
people want to set will involve numbers, so if the only interface was
to pass a string, that just means snprintf() or sbuf-print stuff in
every driver that wants to use it.  Might as well just do the printf
implementation in the function everyone already has to call.

-- Ian