On Feb 17, 2010, at 10:04 AM, Enrico Weigelt weig...@metux.de wrote:
* Steve Simon st...@quintile.net wrote:
We recompile the relevant executables. The speed of kencc makes this
much less painful than you might expect. It also happens very rarely
on plan9 - I cannot remember the last time
On Feb 17, 2010, at 1:21 PM, Enrico Weigelt weig...@metux.de wrote:
* David Leimbach leim...@gmail.com wrote:
A lot of plug in functionality you'll find on other platforms
that requires a shared library approach can be implemented via
a file system service technique.
Of course, and I
On Wed, Feb 17, 2010 at 02:31:09PM +0100, Enrico Weigelt wrote:
Hi folks,
just curious: which binfmt does Plan9 use ?
How are share libraries handled (if they exist at all) ?
Inspired by recent discussions @ gentoo-user, I'm thinking a bit
how an simple and efficient binfmt could look
* Jacob Todd jaketodd...@gmail.com wrote:
Where was this thread at? I'm subscribed to gentoo-user, but I don't have
any threads about binary formats in my inbox. Was the discussion in
another thread (maybe the giant HAL thread)?
Exactly this one ;-p
Oh, and we also talk about fat vs. tiny
On Wed, Feb 17, 2010 at 2:31 PM, Enrico Weigelt weig...@metux.de wrote:
Hi folks,
just curious: which binfmt does Plan9 use ?
How are share libraries handled (if they exist at all) ?
a.out(6)
no shared libraries.
Inspired by recent discussions @ gentoo-user, I'm thinking a bit
how an
Oh, and we also talk about fat vs. tiny libraries, etc.
Maybe you'd like to join in ;-)
please remember that this isn't a linux list.
- erik
And all of the below are some of the reasons I still love plan 9.
Simplicity first is a really great way to work (I've learned over the
years).
Dave
On Wed, Feb 17, 2010 at 6:06 AM, Gorka Guardiola pau...@gmail.com wrote:
On Wed, Feb 17, 2010 at 2:31 PM, Enrico Weigelt weig...@metux.de wrote:
* Gorka Guardiola pau...@gmail.com wrote:
On Wed, Feb 17, 2010 at 2:31 PM, Enrico Weigelt weig...@metux.de wrote:
Hi folks,
just curious: which binfmt does Plan9 use ?
How are share libraries handled (if they exist at all) ?
a.out(6)
no shared libraries.
ah, already suspected that
* the whole loader sits in the kernel (maybe w/ some additional
helper deamon in userland), but userland can pass parameters
like search pathes, etc via env.
IMHO having the dynamic loader in kernel-land (in contrary to ELF
on GNU) not just removes the need for lots of syscalls, but
And another important feature of shared libraries is, that when
some lib is updated, importing programs dont have to be recompiled.
What's the Plan9 solution here ?
We recompile the relevant executables. The speed of kencc makes this
much less painful than you might expect. It also happens
* blstu...@bellsouth.net blstu...@bellsouth.net wrote:
If you're interested in how to do dynamic loading in a clean
and elegant way, take a look at Inferno.
hmm, isnt this an interpreter-based system ?
Along the lines of what you're suggesting, everything is a module.
The only thing
* Steve Simon st...@quintile.net wrote:
We recompile the relevant executables. The speed of kencc makes this
much less painful than you might expect. It also happens very rarely
on plan9 - I cannot remember the last time we had a big pull.
Okay, but then (as an admin) you have to know which
* blstu...@bellsouth.net blstu...@bellsouth.net wrote:
If you're interested in how to do dynamic loading in a clean
and elegant way, take a look at Inferno.
hmm, isnt this an interpreter-based system ?
The application language is Limbo which is compiled to
Dis machine code. Dis is run
We recompile the relevant executables. The speed of kencc makes this
much less painful than you might expect. It also happens very rarely
on plan9 - I cannot remember the last time we had a big pull.
Okay, but then (as an admin) you have to know which apps have
to be recompiled. For a
We recompile the relevant executables. The speed of kencc makes this
much less painful than you might expect. It also happens very rarely
on plan9 - I cannot remember the last time we had a big pull.
Okay, but then (as an admin) you have to know which apps have
to be recompiled. For a small
On Wed, Feb 17, 2010 at 6:55 AM, Steve Simon st...@quintile.net wrote:
And another important feature of shared libraries is, that when
some lib is updated, importing programs dont have to be recompiled.
What's the Plan9 solution here ?
We recompile the relevant executables. The speed of
On 2/17/10, Steve Simon st...@quintile.net wrote:
And another important feature of shared libraries is, that when
some lib is updated, importing programs dont have to be recompiled.
What's the Plan9 solution here ?
We recompile the relevant executables.
also, plan 9 uses filesystems for many
On Wed, Feb 17, 2010 at 8:14 AM, Stuart Morrow morrow.stu...@googlemail.com
wrote:
On 2/17/10, Steve Simon st...@quintile.net wrote:
And another important feature of shared libraries is, that when
some lib is updated, importing programs dont have to be recompiled.
What's the Plan9
And if you do want to
recompile everything, running mk in /sys/src will recompile
everything and not take all that long doing it, especially if you
keep the object files around.
And I can vouch for the fact that this works just fine for the ARM
(impersonated in this case by a SheevaPlug)
* David Leimbach leim...@gmail.com wrote:
A lot of plug in functionality you'll find on other platforms
that requires a shared library approach can be implemented via
a file system service technique.
Of course, and I would really like to see that approach in the GNU
world too (actually, I
Okay, but then (as an admin) you have to know which apps have
to be recompiled. For a small system this might be okay, but
that doesnt scale well ;-o
Plan 9 _is_ a small system.
Even synthetic filesystems are good for moving bigger things to their
own services, there're many cases where that wouldnt make sense, for
example parsers. I doubt you'd really suggest putting an XML parser
to its own filesystem for real productional use ;-p (having such a
thing surely is a
On Wed, Feb 17, 2010 at 10:21 AM, Enrico Weigelt weig...@metux.de wrote:
* David Leimbach leim...@gmail.com wrote:
A lot of plug in functionality you'll find on other platforms
that requires a shared library approach can be implemented via
a file system service technique.
Of course, and
Enrico Weigelt weig...@metux.de wrote:
And another important feature of shared libraries is, that when
some lib is updated, importing programs dont have to be recompiled.
Enrico Weigelt weig...@metux.de wrote:
Actually, that's just a matter of clean dependency handling.
Include an API/ABI
* David Leimbach leim...@gmail.com wrote:
No I'm not saying replace all library code with filesystems. I don't know
why you'd want an RPC interface to an XML parser :-).
You need to implement an RPC protocol for that. And most likely you
want to get the parsed content into some convenient
* Enrico Weigelt weig...@metux.de wrote:
* David Leimbach leim...@gmail.com wrote:
No I'm not saying replace all library code with filesystems. I don't know
why you'd want an RPC interface to an XML parser :-).
You need to implement an RPC protocol for that. And most likely you
want to
On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote:
* each module may have an entry point (main module w/o is allowed,
even if it wouldn't make much sense ;-o), these are called after
relocation, along the dependency tree, from leaf to root.
no modules.
That's not entirely
Nathaniel W Filardo n...@cs.jhu.edu said:
On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote:
* each module may have an entry point (main module w/o is allowed,
even if it wouldn't make much sense ;-o), these are called after
relocation, along the dependency tree, from
On Wed, Feb 17, 2010 at 3:16 PM, EBo e...@sandien.com wrote:
Nathaniel W Filardo n...@cs.jhu.edu said:
On Wed, Feb 17, 2010 at 03:06:57PM +0100, Gorka Guardiola wrote:
* each module may have an entry point (main module w/o is allowed,
even if it wouldn't make much sense ;-o), these
On Wed, Feb 17, 2010 at 03:33:03PM +0100, Enrico Weigelt wrote:
ah, already suspected that ;-o
I know that plan9's standard libraries are so small, that they
dont really need to be shared. But when more and more applications
von *nix world get ported, the problem might arise again.
And
30 matches
Mail list logo