Hi,
I am in the process of writing a module that collects kernel
information of various kernel subsytems and pass this on to a remote
monitoring/management node. The information could be statistical data
maintained in data structures of memory, process, network and so on.
Or it could be any kernel variables that are of interest.
Can you let me know to what extent I can realise my goal ? I have hit
the stumbling block already because the scope of information that is
accessible from the module is restricted only to the exported symbols.
Is there a way of accessing proc information from the module ?
Any input from you would be of great help to my project.
Regards
Anand
On Tue, 2006-03-21 at 16:32 +0530, Anand SVR wrote:
> Hi,
>
> I am in the process of writing a module that collects kernel
> information of various kernel subsytems and pass this on to a remote
> monitoring/management node. The information could be statistical data
> maintained in data structures of memory, process, network and so on.
> Or it could be any kernel variables that are of interest.
you forgot to attach your source code ;)
> Is there a way of accessing proc information from the module ?
eh why on earth is your code in the kernel then? Shouldn't your code be
in userspace if you want to send such information to a remote system???
Hi,
I forgot to mention one more context. In the embedded environment where
one is memory constrained, the lightweight and low memory foot-print
module I am referring to becomes relevant. In addition, since it is
highly reliable, and remotely manageable as listed below I feel it is
worth pursuing.
Thanks for your time.
Regards
Anand
On 3/21/06, Anand SVR <[email protected]> wrote:
> Hi,
>
> The code is not yet ready :) I have a basic version that gives part of
> memory statistics.
>
> Why I want to do it in kernel ? Following are the reasons.
>
> - Not all the information is available to the user space. There may be
> situations where kernel developers, carrier grade server mainatainers,
> and the like might want to access some internal run-time information
> for debugging, fine-tuning and so on.
>
> - Keep it light weight, and least intrusive to the run-time behavior
> of the system. No need for tcp/udp socket communication.
>
> - There could be impending catastrophic situations where in kernel
> cannot schedule user level processes, perhaps due to lack of memory or
> whatever.
>
> - Ability for the remote node to change/control certain kernel
> parameters by interacting with the module. This paves way for both
> diagnosing and controlling kernel.
>
> Regards
> Anand
>
> On 3/21/06, Arjan van de Ven <[email protected]> wrote:
> > On Tue, 2006-03-21 at 16:32 +0530, Anand SVR wrote:
> > > Hi,
> > >
> > > I am in the process of writing a module that collects kernel
> > > information of various kernel subsytems and pass this on to a remote
> > > monitoring/management node. The information could be statistical data
> > > maintained in data structures of memory, process, network and so on.
> > > Or it could be any kernel variables that are of interest.
> >
> > you forgot to attach your source code ;)
> >
> > > Is there a way of accessing proc information from the module ?
> >
> > eh why on earth is your code in the kernel then? Shouldn't your code be
> > in userspace if you want to send such information to a remote system???
> >
> >
> >
>
You can use kernel probes (kprobe & jprobe) for accessing any
variables in the kernel. But ofcourse, this would be running-kernel
specific.
Link http://www.redhat.com/magazine/005mar05/features/kprobes/
Changing the kernel parameters is gonna be a very dangerous act,
unless you are sure of what you are doing.
-- Sumit
On 3/22/06, Anand SVR <[email protected]> wrote:
> Hi,
>
> I forgot to mention one more context. In the embedded environment where
> one is memory constrained, the lightweight and low memory foot-print
> module I am referring to becomes relevant. In addition, since it is
> highly reliable, and remotely manageable as listed below I feel it is
> worth pursuing.
>
> Thanks for your time.
>
> Regards
> Anand
> On 3/21/06, Anand SVR <[email protected]> wrote:
> > Hi,
> >
> > The code is not yet ready :) I have a basic version that gives part of
> > memory statistics.
> >
> > Why I want to do it in kernel ? Following are the reasons.
> >
> > - Not all the information is available to the user space. There may be
> > situations where kernel developers, carrier grade server mainatainers,
> > and the like might want to access some internal run-time information
> > for debugging, fine-tuning and so on.
> >
> > - Keep it light weight, and least intrusive to the run-time behavior
> > of the system. No need for tcp/udp socket communication.
> >
> > - There could be impending catastrophic situations where in kernel
> > cannot schedule user level processes, perhaps due to lack of memory or
> > whatever.
> >
> > - Ability for the remote node to change/control certain kernel
> > parameters by interacting with the module. This paves way for both
> > diagnosing and controlling kernel.
> >
> > Regards
> > Anand
> >
> > On 3/21/06, Arjan van de Ven <[email protected]> wrote:
> > > On Tue, 2006-03-21 at 16:32 +0530, Anand SVR wrote:
> > > > Hi,
> > > >
> > > > I am in the process of writing a module that collects kernel
> > > > information of various kernel subsytems and pass this on to a remote
> > > > monitoring/management node. The information could be statistical data
> > > > maintained in data structures of memory, process, network and so on.
> > > > Or it could be any kernel variables that are of interest.
> > >
> > > you forgot to attach your source code ;)
> > >
> > > > Is there a way of accessing proc information from the module ?
> > >
> > > eh why on earth is your code in the kernel then? Shouldn't your code be
> > > in userspace if you want to send such information to a remote system???
> > >
> > >
> > >
> >
> -
> 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/
>
Hi,
The module is going to be "memory less" in the sense that it only fetches data
of interest that is already maintained in the kernel, forms a message
and send it. In terms of memory, may be few skbs might be consumed for
sending the data across for remote monitoring. This is the main
objective of the project.
Yes, for controlling the kernel parameters one may have to add logic,
but I would
presume that is not going to be too complex and big.
Regards
Anand
On 3/21/06, Arjan van de Ven <[email protected]> wrote:
> On Tue, 2006-03-21 at 21:39 +0530, Anand SVR wrote:
> > Hi,
> >
> > I forgot to mention one more context. In the embedded environment where
> > one is memory constrained, the lightweight and low memory foot-print
> > module I am referring to becomes relevant.
>
> that is a questionable argument; kernel memory is non-pagable while
> userspace memory is, so for me the tradeoff isn't immediately a clear
> win for doing it in the kernel..
>
>