lkml.org 
[lkml]   [1998]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)
On Sun, 31 May 1998, Riccardo Facchetti wrote:
> On Sun, 31 May 1998, James Mastros wrote:
> > There is one really important distinction here: the /proc/pci database
> > needed to be updated regularly, the /proc/config[.gz] dosn't need to be.
>
> Yes ... and there are mantainers of pci database and they could post
> patches on a regular basis to Linus, but this option was discarded.
The problem wasn't that it takes non-zero work to keep the database up to
date, but that it makes kernels "age" with time. PCI devices (ought to)
come out far faster then stable kernels. (Anyway, this bit is off-topic for
the current thread.)

> > With
> > /proc/config[.gz], we can't get equivlent features without being in
> > kernelspace, because the whole point is that kernelspace knows the options.
>
> Why ? If you make sure to associate (in some secure way) the running
> kernel with a file containing the infos, you can have no kernelspace
> bloating.

This patch is missing the "secure way" part (as you noted in the snipped
part below <G>). At the moment, it isn't really any better then just saying
"keep kernels in /boot/kernel/foo and System.maps in /boot/System.map-foo,
where foo=foo". That's the system I use, and it very rarely fails for me
(on occasion I forget to copy the System.map -- I could just create a
makefile target for it, and have essentially your solution, except leaving
out the fooling around with object files.)

[...]
> > This fails the userspace test. ("Can you have equivlent functionality by
> > putting [more of] this in userspace?")
>
> Another interesting question. I have a /proc driver and an user-space
> utility too. Choose one ... they both work well :)
> User-space is better: no kernel bloating at all, even no /proc driver.
> Kernel-space is ... hmm ... was just a good exercise ... I feel kernel
> space driver is less than interesting ... we can do all within user space.

If we can do all within user space, we generaly should. (I realize you
meant "we can all do it within user space", but it works both ways.)

> > > - Data is NOT linked into the kernel (~ 130 Kb of data), so NO kernel
> > > bloat, except of course for the /proc code.
[...]
> > Where are you getting 130 KB?
[...]
> I am talking about System.map, not .config :)
Whops. Anyway, that's 43 KB for the largest System.map I have on file,
after gziping.

> Anyway okay okay ... the real problem is that the idea of cat data at the
> end of kernel image apply to both.
Yeha, it's an interesting idea. I generaly prefer filesystems though --
that is kind of why they were invented. A place for everything and
everything in it's place. And the place for the system.map is, IMHO, not
tacked after the end of the zImage.

[...]
> > I'm no ueber-hacker, but I hope that you care about the thoughts of us
> > Little People too. <G>
>
> I'm Little People me too. Of course I care about any good thought.
[...]
I think you missed the grin on that one!

> Ciao,
> Riccardo.
C-Ya!
-=- James Mastros
--
True mastery is knowing enough to bullshit the rest.
-=- Me
http://www.rtweb.net/theorb coming soon (or when I get around to it).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.075 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site