On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote: > On Fri, 29 May 2020, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > Often enough all we need to do is create a subdirectory so that > > we can stuff sysctls underneath it. However, *if* that directory > > was already created early on the boot sequence we really have no > > need to use the full boiler plate code for it, we can just use > > local variables to help us guide sysctl to place the new leaf files. > > I find it hard to figure out the lifetime requirements for the tables > passed in; when it's okay to use local variables and when you need > longer lifetimes. It's not documented, everyone appears to be using > static tables for this. It's far from obvious. I agree 2000% that it is not obvious. What made me consider it was that I *knew* that the base directory would already exist, so it wouldn't make sense for the code to rely on earlier parts of a table if part of the hierarchy already existed. In fact, a *huge* part of the due dilligence on this and futre series on this cleanup will be to be 100% sure that the base path is already created. And so this use is obviously dangerous, you just *need* to know that the base path is created before. Non-posted changes also deal with link order to help address this in other places, given that link order controls how *initcalls() (early_initcall(), late_initcall(), etc) are ordered if you have multiple of these. I had a link order series long ago which augmented our ability to make things clearer at a link order. Eventually I believe this will become more important, specially as we end up wanting to async more code. For now, we can only rely on manual code inspection for ensuring proper ordering. Part of the implicit aspects of this cleanup is to slowly make these things clearer for each base path. So... the "fs" base path will actually end up being created in fs/sysctl.c after we are *fully* done with the fs sysctl cleanups. Luis _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
