Re: simplify procfs code for seq_file instances
Alexey Dobriyan <[email protected]> Thu, 26 Apr 2018 00:24:11 +0300
| Newsgroups | gmane.comp.file-systems.jfs.general |
|---|---|
| Message-ID | <20180425212411.GB9020__27225.2426286743$1524691345$gmane$org@avx2> |
On Tue, Apr 24, 2018 at 06:06:53PM +0200, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:19:16AM -0700, Andrew Morton wrote: > > > > I want to ask if it is time to start using poorman function overloading > > > > with _b_c_e(). There are millions of allocation functions for example, > > > > all slightly difference, and people will add more. Seeing /proc interfaces > > > > doubled like this is painful. > > > > > > Function overloading is totally unacceptable. > > > > > > And I very much disagree with a tradeoff that keeps 5000 lines of > > > code vs a few new helpers. > > > > OK, the curiosity and suspense are killing me. What the heck is > > "function overloading with _b_c_e()"? > > The way I understood Alexey was to use have a proc_create macro > that can take different ops types. Although the short cut for > __builtin_types_compatible_p would be _b_t_c or similar, so maybe > I misunderstood him. That's correct. I also think that several dozens kmalloc signatures are a problem. And there will be more with pmalloc* stuff and more 2D/3D array checked allocations and who knows what. And I want to add typed kmalloc! ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot