Re: Debian kernel and /proc/pal
On Tue, 2005-08-09 at 10:43 -0700, Stephane Eranian wrote:
> Dann,
>
> On Tue, Aug 09, 2005 at 10:40:16AM -0600, dann frazier wrote:
> > On Mon, 2005-08-08 at 10:17 +1000, Ian Wienand wrote:
> > > On Fri, Aug 05, 2005 at 01:36:54PM +0200, Stephane Eranian wrote:
> > > > I recently used an Itanium machine booted with a 2.6 Linux kernel.
> > > > The exact package is:
> > > > kernel-image-2.6.11-1-mckinley-smp_2.6.11-6_ia64.deb
> > > >
> > > > It does appear that this kernel is compiled without CONFIG_PALINFO
> > > > which means there is no /proc/pal/cpu* entries.
> > >
> > > I filed this under
> > >
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321885
> > >
> > > for the latest 2.6.12 packages which have the same thing.
> > >
> >
> > Note that CONFIG_PALINFO was set to m - most things in Debian kernels
> > are set to build as a module, if possible.
> >
>
> What's the value of having PALINFO as module?
(cc'ing debian-ia64, since this is really a debian issue not a kernel
one)
We don't examine all the bits of code that can be built as modules and
make a decision based on potential performance impact, security risks,
etc - its easier/more consistent to just build as a module if possible.
I don't know of any significant reason to leave palinfo as a module,
which is why I changed it :) However, users who build their own kernels
may still build it as a module. If they do, it'd be good if userspace
utilities either attempted to load it or complained that it wasn't
available. (I've no idea if pfmon already does this or not)
> The firmware interface does not evolve very often.
>
> If module is preferred then, some rc scripts should load it automatically
> somehow.
If a user has a made a conscious choice to build it as a module, then it
probably means that they don't want the code loaded all the time. In
such a situation, its probably better to load on demand or tell the user
to run modprobe themselves instead of auto-loading at boot.
Reply to: