>From the positive and negative feed back that I have recieved so far, I
was going to add the following features to 'netconsole':
1. read the updates file (similar to the web interface) and hide the
event or display the status line. This is doable fairly easily.
The only problem is the real-estate on the 80 char screen.
I dont want to add authentication etc. into the curses interface and
make it overly complicated, hence editing the 'updates' file will still
have to be using an external editor or else from the Web interface.
2. A lot of folks like the web interface, so I dont see a need to replace
it with a X or tcl interface and achieve the same 'gui' look.
3. I was going to add a 'dependency' filter to netconsole:
List all the variables at the various layers i.e.
NewsPort, SMTPport, etc. depend on ICMP
so if ICMP goes down, then the other variables are expected to go down
and need not display them.
Similarly, build a device dependency:
NewsServer depends on RouterA depends on RouterB
Hence, if routerB goes dead, the other devices behind it are expected
to go down also so DONT display them if they also go down.
A sort of a 'root-cause' filter.
Note that this is for *display* purposes only- all noclogd logging will
still continue as is.
The problem is finding a good way to write all these dependency rules
without expecting everyone to be a C programmer ?
-vikas
> The easiest way to do something like this would be to split the objects up
> into two layers; the event layer which reads the events and reports them
> to whatever higher layers request it, and the output layer which all of
>
> It may also be a nice idea to implement them all into one binary, towhich
> you could type 'netconsole -t vt100' and get a vt100 output, or
> 'netconsole -t x' and get an x window, etc. This goes along with my other
> >
> > However..... having hacked curses full time for a number of
> > months I can relate to Vikas's attitude!
> >
> > What about replacing "netconsole" with two interfaces which
> > don't involve curses:
|