On Monday 24 August 2009 18:08:17 Andrew Lunn wrote:
No i've not asked yet. However, i don't know of any other kernel module which does debug output in a similar way. So my guess is this needs changing.
I keep intending to make a ToDo list. Here is what i have in my mind at the moment. Some are just questions/ideas and all of it needs discussing.
I also believe that the logging probably needs to be reworked as well as other things. But I'd rather check with some kernel maintainers first before we start a bigger rework process based on assumptions. Maybe they tell us that this module will never be included because they don't think this is the way to do it.
The todo list is a great start. I imagine it could help us when we talk to the maintainers.
Finish stripping out debug_log.
Probably ok but how do we handle the routing protocol debugging stuff ? Should we pipe everything through printk ? Actually, that considerably slows down the system because many distros write that into a log file.
Make batctl standalone.
What does that mean ?
Maybe make batctl _The_ tool for configuration and status and depreciate direct proc access, so that we can restructure it without too much pain for users.
Handling everything via ioctls ?
Take out the dot_draw/josm formatting in vis and put it into batctl.
Think if /proc/net/batman-adv should be renamed /proc/net/bat0 giving the option of /proc/net/bat1 etc in the future?
Should /proc/net/batman-adv/interface be replaced with an IOCTL interface similar to brctl?
Maybe move orig_interval, aggregate_ogm and write half of vis to /sys? At least spit vis into two.
Investigate if there is a generic linux hash algorithm which should be used?
Strip out all backward compatibility support.
Make use of printk %pM support.
Sounds like a good list.
Regards, Marek