9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Michael Baldwin <michael@cibernet.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: [9fans] dynamic module loading and versioning
Date: Wed, 19 Apr 2006 00:25:54 -0400	[thread overview]
Message-ID: <CB2DA36D-DA67-4958-8658-6AE3E645FBEE@cibernet.com> (raw)
In-Reply-To: <a299efd7396822eb1c307bda2e1e6cb1@swtch.com>

> the boundary is a bit blurred on inferno, because the explicitly
> module loading there is most commonly used to load what on other
> systems would be libraries.  but the result, at least as
> implemented, has a very different feel from the shared library hell
> on unix and windows.

Aren't some of the same maintenance and versioning headaches
associated with shared libraries still there with dynamic loading of
modules?  In Inferno, occasionally the Sys module changes (just to
pick a nasty one), and that can wreak similar havoc as incompatible
shared libraries unless you have a flag day.  I've pondered playing
with the PATH string in a module header to make this less burdensome,
but I haven't seen anyone actually do it or even talk to the issue
(OK, there aren't that (m)any users of Inferno to have people to ask,
I know).

It just seems that, if for some reason I go and change a function
signature in the String module, say, isn't it a similar headache as
shared libraries to keep all the programs that use the old and new
module running and happy at the same time?  I know merely adding
functions is still compatible, but sometimes incompatible changes
must be made (int->big for file sizes and offsets comes to mind).
And to keep old and new programs not just running but compiling is a
bit of a bitch.  Has anyone thought about or addressed these issues
in Inferno or another dynamic-loading system?  Any lessons that can
be learned and brought back to the unwashed world of shared libraries?



  reply	other threads:[~2006-04-19  4:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19  2:35 [9fans] Install from CD fails erik quanstrom
2006-04-19  3:53 ` Russ Cox
2006-04-19  4:25   ` Michael Baldwin [this message]
2006-04-19  9:37     ` [9fans] dynamic module loading and versioning Bruce Ellis
2006-04-19  9:40       ` Lyndon Nerenberg
2006-04-19  9:54         ` Bruce Ellis
2006-04-19 14:12           ` Artem Letko
2006-04-19 17:49             ` Bruce Ellis
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
2006-04-19 19:42   ` Bruce Ellis
2006-04-20  1:07     ` Roman Shaposhnick
2006-04-20  2:02       ` Jack Johnson
2006-04-19 19:45   ` Charles Forsyth
2006-04-19 21:16   ` Brantley Coile
2006-04-19 21:46   ` quanstro
2006-04-20  1:03     ` rog
2006-04-20  6:08       ` Charles Forsyth
2006-04-20 15:59         ` rog
2006-04-20  4:02     ` Roman Shaposhnick

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=CB2DA36D-DA67-4958-8658-6AE3E645FBEE@cibernet.com \
    --to=michael@cibernet.com \
    --cc=9fans@cse.psu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).