[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzrO+ZNmpKetdIPU@paasikivi.fi.intel.com>
Date: Mon, 3 Oct 2022 12:00:57 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Bjorn Andersson <andersson@...nel.org>,
Prashant Malani <pmalani@...omium.org>,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, Daniel Scally <djrscally@...il.com>
Subject: Re: [PATCH v2 1/5] device property: Keep dev_fwnode() and
dev_fwnode_const() separate
Hi Rafael,
On Mon, Oct 03, 2022 at 01:54:37PM +0200, Rafael J. Wysocki wrote:
> > I ask as I just went through a large refactoring of the kobject layer to
> > mark many things const * and I find it a bit "sad" that functions like
> > this:
> > static inline struct device *kobj_to_dev(const struct kobject *kobj)
> > {
> > return container_of(kobj, struct device, kobj);
> > }
> > have the ability to take a read-only pointer and spit out a writable one
> > thanks to the pointer math in container_of() with no one being the
> > wiser.
>
> Well, is this really a problem?
>
> After all, if an immutable structure is embedded in another one, that
> doesn't automatically imply that the containing structure has to be
> immutable too. Hence, a const pointer to the inner structure doesn't
> automatically yield a const pointer to the outer one.
I think in that case it'd be better, to at least make an informed decision
on that instead of just dropping the const qualifier.
--
Regards,
Sakari Ailus
Powered by blists - more mailing lists