Re: Continuing the procfs cleanup
Guest section DW wrote: > From: Alexander Viro <[EMAIL PROTECTED]> > There's actually one more TODO point. And pretty serious one, at it. > We got a severely cluttered namespace under /proc (little gems a-la > /proc/h8 and friends). It's a Bad Thing (tm) for a lot of obvious reasons. > We can move to something saner if > a) we'll agree on a naming policy > b) add a PROC_COMPAT option that would just create a bunch of > static symlinks from old to new locations. > I think starting a PROC_COMPAT option would be a rather bad idea. > In a development series it is permissible to change things, > and in a new stable release one may require people to upgrade > utilities. Having PROC_COMPAT only complicates things - it will > cause problems instead of solving them. Yes, I am beginning to agree with this viewpoint much more Moving things around in /proc is really an issue that needs to be solved on a driver-to-driver basis. Also, some drivers can simply be converted to the new proc_driver_xxx helper, which automatically puts things inside "/proc/drivers" sub-directory.
Continuing the procfs cleanup (was Re: updates to procfs?)
Alexander Viro wrote: > > On Tue, 19 Oct 1999, Jeff Garzik wrote: > > > Comments on your procfs patch: I like it. :) > > > > It looks like many xxx_read_proc operation in fs/proc/proc_array.c > > contains the _exact_ same code for adjusting 'len', 'start', etc. > > Cleanup should take care of that. > > > > Putting that stuff into an inline or plain macro would save a lot of > > [source] code. But I think proc_array.c can be made even smaller. > > Maybe 80% of the functions could be condensed into something like: > > > > DECLARE_SIMPLE_READ_PROC(filesystems_read_proc, get_filesystem_list) > > DECLARE_SIMPLE_READ_PROC(dma_read_proc, get_dma_list) > > Yes, but it's _not_ a good thing. See comment in the beginning of > proc_misc.c - the thing you are talking about is the wrapper turning > ->info-ish stuff into ->read_proc one. It's OK for the small things, but > for anything large... Look into drivers/pci/proc.c - I did a proper > conversion there and IMO the same should be done for the rest of them. Ok, well my main complaint is that there is duplicate code no matter how you scatter or update things. In pci_read_proc there is logic to calculate 'count', 'eof', etc. which is duplicated many times. My idea for solving this is to create struct proc_print, and function proc_printk: int proc_printk (struct proc_print *p, const char *format, ...) 'struct proc_print' would contain all the args passed to xxx_read_proc, and proc_printk would update that information each time it is called. proc_printk can also be set up to handle overflows of the procfs output buffer, multiple output buffers, etc.
Re: Continuing the procfs cleanup
From: Alexander Viro <[EMAIL PROTECTED]> There's actually one more TODO point. And pretty serious one, at it. We got a severely cluttered namespace under /proc (little gems a-la /proc/h8 and friends). It's a Bad Thing (tm) for a lot of obvious reasons. We can move to something saner if a) we'll agree on a naming policy b) add a PROC_COMPAT option that would just create a bunch of static symlinks from old to new locations. c) for unimportant (== used by a couple of driver-related utilities) things - remove the links when the utilities will be updated d) for important stuff - gather the links into proc_compat.o and make it a module. And ask everybody to use the new locations, so that folks who are not stuck with old binaries might completely get rid of the clutter. (a) is obviously the trickiest ;-/ I think starting a PROC_COMPAT option would be a rather bad idea. In a development series it is permissible to change things, and in a new stable release one may require people to upgrade utilities. Having PROC_COMPAT only complicates things - it will cause problems instead of solving them. But it may be premature to worry about PROC_COMPAT. Let us first design the new interface, then how to go from old to new can be discussed later. Andries
Re: Continuing the procfs cleanup
On Wed, 27 Oct 1999, Jeff Garzik wrote: > Alex, > > I now have most of your procfs patch ported to the latest kernels, at > >http://gtf.org/garzik/kernel/files/UNTESTED/proc_cleanup_19991026-2.3.24-pre1.patch.gz > > Note this is a --cvs patch-- and thus not easily applied by patch. Thanks. I'll look at it ASAP. > It compiles against 2.3.24 pre1, and probably(tm) works. > > The next step in my plan for feeding patches to Linus is to test the > cleanup of fs/proc/* and send that to Linus -- EXCEPT temporarily keep > the proc_net_register function. (it will go away later) If I don't do > that, I am forced to send all the procfs net code updates too. > > After that goes in, the remaining drivers and the networking code will > be cleaned up. Most of the networking code is already updated as you > will see from the patch above. > > TODO: > * merge the rest of your procfs patch, mainly drivers/* is left now > > * go through and audit each file to make sure a create_xxx is followed > by remove_xxx. Many times it is not, which will cause an oops as you > know > > * ...the other TODO items you posted about in the "updates to procfs" > thread There's actually one more TODO point. And pretty serious one, at it. We got a severely cluttered namespace under /proc (little gems a-la /proc/h8 and friends). It's a Bad Thing (tm) for a lot of obvious reasons. We can move to something saner if a) we'll agree on a naming policy b) add a PROC_COMPAT option that would just create a bunch of static symlinks from old to new locations. c) for unimportant (== used by a couple of driver-related utilities) things - remove the links when the utilities will be updated d) for important stuff - gather the links into proc_compat.o and make it a module. And ask everybody to use the new locations, so that folks who are not stuck with old binaries might completely get rid of the clutter. (a) is obviously the trickiest ;-/
Continuing the procfs cleanup
Alex, I now have most of your procfs patch ported to the latest kernels, at http://gtf.org/garzik/kernel/files/UNTESTED/proc_cleanup_19991026-2.3.24-pre1.patch.gz Note this is a --cvs patch-- and thus not easily applied by patch. It compiles against 2.3.24 pre1, and probably(tm) works. The next step in my plan for feeding patches to Linus is to test the cleanup of fs/proc/* and send that to Linus -- EXCEPT temporarily keep the proc_net_register function. (it will go away later) If I don't do that, I am forced to send all the procfs net code updates too. After that goes in, the remaining drivers and the networking code will be cleaned up. Most of the networking code is already updated as you will see from the patch above. TODO: * merge the rest of your procfs patch, mainly drivers/* is left now * go through and audit each file to make sure a create_xxx is followed by remove_xxx. Many times it is not, which will cause an oops as you know * ...the other TODO items you posted about in the "updates to procfs" thread
