From: ebiederm@xmission.com (Eric W. Biederman)
To: "Guillermo López Alejos" <glalejos@gmail.com>
Cc: Linh Dang <linhd@nortel.com>, linux-kernel@vger.kernel.org
Subject: Re: Environment variables inside the kernel?
Date: Mon, 22 Aug 2005 03:18:40 -0600 [thread overview]
Message-ID: <m1r7cmtjm7.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <4fec73ca05082202051231bf15@mail.gmail.com> ( =?iso-8859-1?q?Guillermo_L=F3pez_Alejos's_message_of?= "Mon, 22 Aug 2005 11:05:32 +0200")
Guillermo López Alejos <glalejos@gmail.com> writes:
> On 8/22/05, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> ??
>> Usually when I hear stand-alone program I think of program that runs
>> without the need of a kernel. You have an environment in that context?
>
> Without the need of a kernel?
Yep I think of programs like memtest86 when I think of stand-alone
programs.
> Perhaps I did not explain myself correctly... I meant a user space
> program, is that better?
Yes, thanks.
> And yes, there is a environment in this context, but it is feasible to
> provide the information it contains through module parameters.
>
>> Be very careful. Generally I think at least until the filesystem
>> is very stable running your filesystem server in the kernel is a mistake.
>>
>> And the concept of a parallel filesystem with just one server just
>> sounds wrong from any context.
>
> Thanks for the advise, but do not worry, the servers run outside the
> kernel (preferably outside the host :). It is the client side what is
> to be integrated into the kernel.
Ok. As for parameters I would expect most of them to be mount options.
Just a bit of food for thought. There seem to be two different kinds
of workloads for non-local filesystems. Bandwidth intensive workloads
where files are read and written. Cache intensive workloads (like
kernel compiles) where performance directly relates to how
efficiently you can make use of the page cache, and not get buried
in cache contention.
Eric
next prev parent reply other threads:[~2005-08-22 22:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 15:44 Guillermo López Alejos
2005-08-18 16:02 ` linux-os (Dick Johnson)
2005-08-18 16:03 ` jerome lacoste
2005-08-18 16:12 ` Ingo Oeser
2005-08-18 17:27 ` Christoph Lameter
2005-08-18 16:37 ` Douglas McNaught
2005-08-18 18:23 ` Linh Dang
2005-08-18 18:48 ` Guillermo López Alejos
2005-08-18 19:43 ` Emilio Jesús Gallego Arias
2005-08-21 22:12 ` Eric W. Biederman
2005-08-22 9:05 ` Guillermo López Alejos
2005-08-22 9:18 ` Eric W. Biederman [this message]
2005-08-25 8:59 ` Guillermo López Alejos
2005-08-22 20:38 ` Helge Hafting
2005-08-18 23:12 ` Alan Cox
2005-08-18 22:55 ` Peter M. Groen
2005-08-19 10:28 ` Guillermo López Alejos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r7cmtjm7.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=glalejos@gmail.com \
--cc=linhd@nortel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome