> > We have a process for the latter. And even if we ignore that process, the
> > patch ends up sitting in -mm for ages because of the API change, along with
> > the cleanups, which could be merged up promptly.
>
> The problem is that we have a lack of a process at the other end:
>
> There is no process to review added exports.
>
> And there are so many exports added with "we will soon use them".
.. and many never will, leading to about 900 unused ones, each taking
quite a bit of space.
Some are really stupid (eg sys_openat export is just braindead, sys_open
was temporarily exported until all in-kernel users were switched over to
the firmware loading api, sys_openat seems to just have blindly copied
this without thinking)
> If removing exports requires a process, adding exports requires a
> similar process.
alternatively we should bite the bullet, and just stick those 900 on the
"we'll kill all these in 3 months" list, have a thing to disable them
now via a config option (so that people actually notice rather than just
having them in the depreciation file) and fix the 5 or 10 or so that
actually will be used soon in those 3 months.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
