greg k-h:
>What does everyone else need/want there?
dmidecode, so the init script can dump a DMI report in a known
location such as /var/run/dmi.
I want this for autoconfiguration purposes. If I can have it, I
won't need /proc/dmi.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
I cannot undertake to lay my finger on that article of the
Constitution which grant[s] a right to Congress of expending, on
objects of benevolence, the money of their constituents.
-- James Madison, 1794
Tom Rini wrote:
> On Wed, Jan 09, 2002 at 09:54:28AM -0800, Torrey Hoffman wrote:
>
> > The interesting thing that I currently do with initrd support is a
> > custom network-booted Linux installer for an embedded system.
> >
> > I'd like to be able to do this with initramfs too. It needs:
> [snip]
>
> Er, for this particular application, why would you use klibc, if
> existant? The initramfs stuff could work with glibc, if you
> didn't mind
> a big enough image, it sounds like.
You are correct, the size of glibc is not a major problem for me right
now and that's what I'm using. However, it is the largest thing in my
initrd, which goes across the net using tftp, and glibc just keeps
getting bigger... I'm thinking of switching to ulibc when I get time.
One of the neat things about moving a lot of this formerly in-kernel
boot stuff to userspace is that it will be easier to do interesting
customization of the boot process, without having to hack the kernel.
I'm sure that this will be used in lots of innovative ways that people
haven't even thought of yet.
So, I guess what I'd like to see with the initramfs build system is a
easy way to build little apps like sfdisk and mkreiserfs against the
libc it (normally) uses and add them to the ramdisk.
I'm not so worried for myself, but for an overworked sysadmin trying
to customize the boot it could end up being very confusing...
Torrey
"Eric S. Raymond" <[email protected]> writes:
> greg k-h:
> >What does everyone else need/want there?
>
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.
>
> I want this for autoconfiguration purposes. If I can have it, I
> won't need /proc/dmi.
Why can't this happen inside the regular startup scripts? They know
where to put such files; the kernel-level stuff doesn't--I can't think
of any current situation where the kernel writes to an arbitrary file
in the filesystem as it boots. Sure, /var/run is in the FHS, but that
doesn't mean every system will have it.
IMHO, since /var/run/dmi is not needed by any stage of the kernel
boot, it should be created in the regular startup scripts (invoked by
init(8)).
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> greg k-h:
> >What does everyone else need/want there?
>
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.
Why do you need that during that stage of the boot process? The DMI tables
won't go away.
Besides, is there a way to put them in such a place that when mounting the
real root partition, they won't go away? Or, is the initramfs partition
going to persist during runtime?
However, we may needs parsers to do IRQ routing. Yes, that means (dramatic
horror music) an ACPI interpreter and/or PIRQ table parser.
Which brings me to the question about initramfs configurability. Different
systems have different needs during that process. It seems that we need a
generic way to build applications for initramfs (and link them against the
libc that's used) and build initramfs images.
If building the image is part of the kernel build process, then it's
not an issue. But, it would be nice, IMHO, to separate the two; so you
could build a new initramfs image and tack it on to an already built
kernel...
-pat
Doug McNaught <[email protected]>:
> "Eric S. Raymond" <[email protected]> writes:
>
> > greg k-h:
> > >What does everyone else need/want there?
> >
> > dmidecode, so the init script can dump a DMI report in a known
> > location such as /var/run/dmi.
> >
> > I want this for autoconfiguration purposes. If I can have it, I
> > won't need /proc/dmi.
>
> Why can't this happen inside the regular startup scripts? They know
> where to put such files; the kernel-level stuff doesn't--I can't think
> of any current situation where the kernel writes to an arbitrary file
> in the filesystem as it boots. Sure, /var/run is in the FHS, but that
> doesn't mean every system will have it.
>
> IMHO, since /var/run/dmi is not needed by any stage of the kernel
> boot, it should be created in the regular startup scripts (invoked by
> init(8)).
You're right, I don't need this to be done at kernel level. I do need it to
be done *everywhere*. I'm not sure how else to guarantee this will happen.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The American Republic will endure, until politicians realize they can
bribe the people with their own money.
-- Alexis de Tocqueville
"Eric S. Raymond" <[email protected]> writes:
> You're right, I don't need this to be done at kernel level. I do need it to
> be done *everywhere*. I'm not sure how else to guarantee this will happen.
Time to call in your chits with Red Hat and the other distributors. ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
Patrick Mochel <[email protected]>:
>
> On Wed, 9 Jan 2002, Eric S. Raymond wrote:
>
> > greg k-h:
> > >What does everyone else need/want there?
> >
> > dmidecode, so the init script can dump a DMI report in a known
> > location such as /var/run/dmi.
>
> Why do you need that during that stage of the boot process? The DMI tables
> won't go away.
I know. My proposal to put dmidecode in initramfs is an alternative to
/proc/dmi, one which won't involve having dmidecode run in kernelspace.
The underlying problem is that dmidecode needs access to kmem, and I can't
assume that the person running my configurator will be root.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The whole of the Bill [of Rights] is a declaration of the right of the
people at large or considered as individuals... It establishes some
rights of the individual as unalienable and which consequently, no
majority has a right to deprive them of.
-- Albert Gallatin, Oct 7 1789
On Wed, Jan 09, 2002 at 03:44:25PM -0500, Eric S. Raymond wrote:
>
> You're right, I don't need this to be done at kernel level. I do need it to
> be done *everywhere*. I'm not sure how else to guarantee this will happen.
Then add an init script and include installation of it to the
installation steps of your autoconfigurator (it has to be installed
anyway). If a distributor packages your program, he will include the
init script into his package and enable it according to his init
policy, or write an own init script, if your provided one doesn't
fit.
That's the way it works for network daemons etc. for years.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - [email protected] - http://www.devcon.net
Andreas Ferber <[email protected]>:
> Then add an init script and include installation of it to the
> installation steps of your autoconfigurator (it has to be installed
> anyway). If a distributor packages your program, he will include the
> init script into his package and enable it according to his init
> policy, or write an own init script, if your provided one doesn't
> fit.
>
> That's the way it works for network daemons etc. for years.
This sounds like good advice. The autoconfigurator is part of CML2,
which I expect to be distributed with the kernel. Does that change
your advice at all?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Those who make peaceful revolution impossible
will make violent revolution inevitable."
-- John F. Kennedy
On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> The underlying problem is that dmidecode needs access to kmem, and I
> can't assume that the person running my configurator will be root.
But you can "su -c" (also sudo, I suppose). If that person
doesn't have root, then building a kernel isn't going to do
them much good.
Matthew.
Matthew Kirkwood <[email protected]>:
> > The underlying problem is that dmidecode needs access to kmem, and I
> > can't assume that the person running my configurator will be root.
>
> But you can "su -c" (also sudo, I suppose). If that person
> doesn't have root, then building a kernel isn't going to do
> them much good.
We've been over this already. No, the configurator user should *not* have
to su at any point before actual kernel installation. Bad practice,
no doughnut.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create...."
-- Chief Justice John Marshall, 1819.
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Andreas Ferber <[email protected]>:
> > Then add an init script and include installation of it to the
> > installation steps of your autoconfigurator (it has to be installed
> > anyway). If a distributor packages your program, he will include the
> > init script into his package and enable it according to his init
> > policy, or write an own init script, if your provided one doesn't
> > fit.
> >
> > That's the way it works for network daemons etc. for years.
>
> This sounds like good advice. The autoconfigurator is part of CML2,
> which I expect to be distributed with the kernel. Does that change
> your advice at all?
>
The program at hand is actually dmiparse or whatever it's called. If
dmiparse isn't available, or its input data, print an eror message.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Matthew Kirkwood <[email protected]>:
> > > The underlying problem is that dmidecode needs access to kmem, and I
> > > can't assume that the person running my configurator will be root.
> >
> > But you can "su -c" (also sudo, I suppose). If that person
> > doesn't have root, then building a kernel isn't going to do
> > them much good.
>
> We've been over this already. No, the configurator user should *not* have
> to su at any point before actual kernel installation. Bad practice,
> no doughnut.
>
We have also been over the fact that dmidecode, if written
appropriately, could be setuid, or call a "dmicat" setuid program.
This is a dmidecode implementation detail.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> > > The underlying problem is that dmidecode needs access to kmem, and I
> > > can't assume that the person running my configurator will be root.
> >
> > But you can "su -c" (also sudo, I suppose). If that person
> > doesn't have root, then building a kernel isn't going to do
> > them much good.
>
> We've been over this already. No, the configurator user should *not*
> have to su at any point before actual kernel installation. Bad
> practice, no doughnut.
Why bad practice? Anyway, you can:
if [ /proc/ -nt /var/run/dmidecode ]; then
echo We need to run some code as root.
echo -n Enter root\'s\
su -c 'dmidecode > /var/run/dmidecode'
fi
Which provides at least a way to have your config tool
work without having to bloat the initramfs.
Matthew.
On Wed, Jan 09, 2002 at 04:56:58PM -0500, Eric S. Raymond wrote:
> > That's the way it works for network daemons etc. for years.
> This sounds like good advice. The autoconfigurator is part of CML2,
> which I expect to be distributed with the kernel. Does that change
> your advice at all?
Yes, a little bit. Make dmidecode (or whatever you also need for
preparation steps that have to be done as root) a separate package,
which has to be installed before "make autoconfig" works, and write
that down in Documentation/Changes.
This gives you several benefits:
- you don't depend on the version of the /running/ kernel for "make
autoconfig" to work (/dev/kmem is available for a /long/ time now).
- you can install and run dmidecode on one machine, copy the retrieved
data to another machine and autoconfigure/build the kernel there.
Distributions can install the package by default, to make it work for
your grandmother as well, if that's what you want.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - [email protected] - http://www.devcon.net
Matthew Kirkwood <[email protected]>:
> > We've been over this already. No, the configurator user should *not*
> > have to su at any point before actual kernel installation. Bad
> > practice, no doughnut.
>
> Why bad practice? Anyway, you can:
>
> if [ /proc/ -nt /var/run/dmidecode ]; then
> echo We need to run some code as root.
> echo -n Enter root\'s\
> su -c 'dmidecode > /var/run/dmidecode'
> fi
>
> Which provides at least a way to have your config tool
> work without having to bloat the initramfs.
OK. One more time.
The autoconfigurator is *not* mean to be run at boot time, or as root.
It is intended to be run by ordinary users, after system boot time.
This is so they can configure and experimentally build kernels without
incurring the "oops..." risks of going root.
Therefore, the above 'solution' is not acceptable.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
A man who has nothing which he is willing to fight for, nothing
which he cares about more than he does about his personal safety,
is a miserable creature who has no chance of being free, unless made
and kept so by the exertions of better men than himself.
-- John Stuart Mill, writing on the U.S. Civil War in 1862
Followup to: <[email protected]>
By author: "Eric S. Raymond" <[email protected]>
In newsgroup: linux.dev.kernel
>
> OK. One more time.
>
> The autoconfigurator is *not* mean to be run at boot time, or as root.
>
> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.
>
> Therefore, the above 'solution' is not acceptable.
>
If /var/run/dmidata [or whatever you call it] isn't available, put an
error box on the screen and say "complain to your distribution
vendor."
End of story.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Wed, Jan 09, 2002 at 12:25:37PM -0800, Torrey Hoffman wrote:
> One of the neat things about moving a lot of this formerly in-kernel
> boot stuff to userspace is that it will be easier to do interesting
> customization of the boot process, without having to hack the kernel.
Right. But in doing this we also don't want to bloat the very small
programs/functionality we currently hack directly in
> I'm sure that this will be used in lots of innovative ways that people
> haven't even thought of yet.
Yes, but how many of these require a 'klibc' ? One of the other tiny
libcs is probably a better bet for any sort of 'large' project. IMHO,
the klibc stuff should be just big enough to support the 'normal' cases,
ie stuff we do now and related.
> So, I guess what I'd like to see with the initramfs build system is a
> easy way to build little apps like sfdisk and mkreiserfs against the
> libc it (normally) uses and add them to the ramdisk.
Well, occording to the spec file hpa posted, it's just a cpio(1)
archive, so anything is possible.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
> We have also been over the fact that dmidecode, if written
> appropriately, could be setuid, or call a "dmicat" setuid program.
> This is a dmidecode implementation detail.
We've also proved the DMI data is too unreliable to be used, so the entire
problem space is irrelevant
On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> > if [ /proc/ -nt /var/run/dmidecode ]; then
> > echo We need to run some code as root.
> > echo -n Enter root\'s\
> > su -c 'dmidecode > /var/run/dmidecode'
> > fi
> The autoconfigurator is *not* mean to be run at boot time, or as root.
Under normal circumstances.
> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.
Then ship it in a separate package with initscripts. Either
CML2 is well enough designed that the autoconfigurator will
not need to change as the kernel does, or all your
overengineering was for nought.
> Therefore, the above 'solution' is not acceptable.
To who? It provides as way for your configurator to function
out-of-the-box until distributions choose whether it's worth
their while to support your scheme.
Matthew.
On Thu, 10 Jan 2002, Alan Cox wrote:
> > We have also been over the fact that dmidecode, if written
> > appropriately, could be setuid, or call a "dmicat" setuid program.
> > This is a dmidecode implementation detail.
> We've also proved the DMI data is too unreliable to be used, so the entire
> problem space is irrelevant
That's not a problem, remember Eric volunteered to maintain the
enormous black list 8-)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Matthew Kirkwood wrote:
> On Wed, 9 Jan 2002, Eric S. Raymond wrote:
>
>>The autoconfigurator is *not* mean to be run at boot time, or as root.
>>
>
> Under normal circumstances.
>
???? Could you tell me about an 'anormal' circumstance that
need autoconfigurator at boot time ?
>
>>It is intended to be run by ordinary users, after system boot time.
>>This is so they can configure and experimentally build kernels without
>>incurring the "oops..." risks of going root.
>>
>
> Then ship it in a separate package with initscripts. Either
> CML2 is well enough designed that the autoconfigurator will
> not need to change as the kernel does, or all your
> overengineering was for nought.
No problem. Autoconfigurator can live without important files.
I.e. no /proc/bus/{pci,usb}, autoconfigurator will ignore such
detections. (it would not say: no PCI cards, but unfortunatelly
it will find only few PCI cards (via /proc/{devices,misc}, if you
have luke)).
BTW: IMHO I can complete the detection, also with ISA cards,
before Eric will start including dmi.
How to handle a driver db with dmi strings and kernel configurations?
It seems to me to complex to try it. We need every possible machine
to extract data.
giacomo
Dave Jones wrote:
> On Thu, 10 Jan 2002, Alan Cox wrote:
>
>>We've also proved the DMI data is too unreliable to be used, so the entire
>>problem space is irrelevant
>>
>
> That's not a problem, remember Eric volunteered to maintain the
> enormous black list 8-)
>
Surelly I will not maintain the DMI table!
It is already difficult to maintain the database of CPU.
The newer CPUs have name stored directly in CPU and no more
in kernel :-(
(
This is a call for help: how to write a table
CPU - CONFIG_SYMBOL ?
Now I use Vendor/Name/Family/Stepping/, but
maybe with Vendor + flags (CPUID flags) the result
will be more correct?
Other suggestions?
giacomo
> Surelly I will not maintain the DMI table!
Quite
> This is a call for help: how to write a table
> CPU - CONFIG_SYMBOL ?
> Now I use Vendor/Name/Family/Stepping/, but
> maybe with Vendor + flags (CPUID flags) the result
> will be more correct?
You need the family/model information to get the right optimisations. Its
often not that the instruction set is different but that the cpu
implementation is different that determines the choice. With a couple of
exceptions cpu type is actually not too important and accidentally using
486 will make little difference
On Thu, 10 Jan 2002, Giacomo Catenazzi wrote:
> It is already difficult to maintain the database of CPU.
> The newer CPUs have name stored directly in CPU and no more
> in kernel :-(
It's worse than you think.
Distinguishing between XP and MP athlon for example needs
capability bit testing. (And some XP's _are_ now multiprocessor
capable, just to confuse the issue some more), so relying on
the cpuid identity string isn't foolproof.
(Also, some implementations allow for this string to be changed,
some folks have it set to "PenguinPowered" and the likes 8-)
> This is a call for help: how to write a table
> CPU - CONFIG_SYMBOL ?
> Now I use Vendor/Name/Family/Stepping/, but
> maybe with Vendor + flags (CPUID flags) the result
> will be more correct?
Asides from the above issues, multiple CPUs have the same
cpuid sometimes, meaning you have to check things like
cache size as well (though most (all?) of these should
end up with the same CONFIG_ option iirc, so this shouldn't
be an issue -- you should check to be sure though)
x86info's identify.c files should give you a fairly
comprehensive guide to the various types.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Alan Cox wrote:
>>Surelly I will not maintain the DMI table!
>>
>
> Quite
>
>
>>This is a call for help: how to write a table
>>CPU - CONFIG_SYMBOL ?
>>Now I use Vendor/Name/Family/Stepping/, but
>>maybe with Vendor + flags (CPUID flags) the result
>>will be more correct?
>>
>
> You need the family/model information to get the right optimisations. Its
> often not that the instruction set is different but that the cpu
> implementation is different that determines the choice. With a couple of
> exceptions cpu type is actually not too important and accidentally using
> 486 will make little difference
>
Something I'd really like to see would be to split "optimize for..." and
"run on..." for CPU type; just like gcc has -mmach= and -march=.
-hpa
Dave Jones wrote:
>
> It's worse than you think.
> Distinguishing between XP and MP athlon for example needs
> capability bit testing. (And some XP's _are_ now multiprocessor
> capable, just to confuse the issue some more), so relying on
> the cpuid identity string isn't foolproof.
> (Also, some implementations allow for this string to be changed,
> some folks have it set to "PenguinPowered" and the likes 8-)
>
Sure, but if you do that you're *asking*, in a very literal way, for
your CPU to misidentified. In fact, a major reason for making this
string modifiable is due to certain vendors who hard-code CPUID strings
in their code.
>
> Asides from the above issues, multiple CPUs have the same
> cpuid sometimes, meaning you have to check things like
> cache size as well (though most (all?) of these should
> end up with the same CONFIG_ option iirc, so this shouldn't
> be an issue -- you should check to be sure though)
>
Why -- if it doesn't change anything, all you're doing is making it
confusing when the next derivative appears. Remember that we *do* need,
as much as possible, to be forward compatible with future CPUs.
> x86info's identify.c files should give you a fairly
> comprehensive guide to the various types.
-hpa
On Thu, 10 Jan 2002, H. Peter Anvin wrote:
> > (Also, some implementations allow for this string to be changed,
> > some folks have it set to "PenguinPowered" and the likes 8-)
> Sure, but if you do that you're *asking*, in a very literal way, for
> your CPU to misidentified. In fact, a major reason for making this
> string modifiable is due to certain vendors who hard-code CPUID strings
> in their code.
Absolutely, no argument from me there.
> > Asides from the above issues, multiple CPUs have the same
> > cpuid sometimes, meaning you have to check things like
> > cache size as well (though most (all?) of these should
> > end up with the same CONFIG_ option iirc, so this shouldn't
> > be an issue -- you should check to be sure though)
> Why -- if it doesn't change anything, all you're doing is making it
> confusing when the next derivative appears. Remember that we *do* need,
> as much as possible, to be forward compatible with future CPUs.
If every combination for a given cpuid translates to the same CONFIG_
option, fine. I'm just not sure from memory if thats the case or not.
The various Celeron/PIII's for example, some have SSE, some don't.
Assuming Intel cpuid xxx translates to CONFIG_PENTIUMIII would break if
thats the case.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones wrote:
>
> If every combination for a given cpuid translates to the same CONFIG_
> option, fine. I'm just not sure from memory if thats the case or not.
> The various Celeron/PIII's for example, some have SSE, some don't.
> Assuming Intel cpuid xxx translates to CONFIG_PENTIUMIII would break if
> thats the case.
>
Right, which is why you should look at the SSE feature flag and nothing
else.
-hpa
On Thu, 10 Jan 2002, H. Peter Anvin wrote:
> Right, which is why you should look at the SSE feature flag and nothing
> else.
Agreed.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, 9 Jan 2002, Eric S. Raymond wrote:
> greg k-h:
> >What does everyone else need/want there?
>
> dmidecode, so the init script can dump a DMI report in a known
> location such as /var/run/dmi.
No, this belongs in a distribution's init scripts. Initramfs is stuff that
is needed before mounting real root, not everything that must be done
before we have a login prompt.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Hi!
> You're right, I don't need this to be done at kernel level. I do need it to
> be done *everywhere*. I'm not sure how else to guarantee this will happen.
Ehm? autoconfig is not good enough reason to force *everyone* to do dmi
scanning. I don't give a damn about autoconfig, and you are not going
to force it to my machines. Stop trying.
It may be reasonable if you wanted major distros to have that. Just don't
say *everyone*.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> > > We've been over this already. No, the configurator user should *not*
> > > have to su at any point before actual kernel installation. Bad
> > > practice, no doughnut.
> >
> > Why bad practice? Anyway, you can:
> >
> > if [ /proc/ -nt /var/run/dmidecode ]; then
> > echo We need to run some code as root.
> > echo -n Enter root\'s> > su -c 'dmidecode > /var/run/dmidecode'
> > fi
> >
> > Which provides at least a way to have your config tool
> > work without having to bloat the initramfs.
>
> OK. One more time.
>
> The autoconfigurator is *not* mean to be run at boot time, or as root.
>
> It is intended to be run by ordinary users, after system boot time.
> This is so they can configure and experimentally build kernels without
> incurring the "oops..." risks of going root.
>
> Therefore, the above 'solution' is not acceptable.
Therefore, autoconfigurator is not acceptable. Tada.
You can't go around saying "my autoconfigurator needs this so put it into
kernel". autoconfigurator is not important enough to touch kernel/initrd.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.