[9fans] plan9port lacks exportfs server - Plan9

This is a discussion on [9fans] plan9port lacks exportfs server - Plan9 ; Guys, somehow it dawned on me that plan9port lacks an application to serve a local filesystem over 9P. Is this on purpose? Am I missing something fundamental that would allow for a moral equivalent of exportfs? The best I could ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: [9fans] plan9port lacks exportfs server

  1. [9fans] plan9port lacks exportfs server

    Guys,

    somehow it dawned on me that plan9port lacks
    an application to serve a local filesystem
    over 9P. Is this on purpose? Am I missing
    something fundamental that would allow
    for a moral equivalent of exportfs?

    The best I could come up with was to possibly
    use u9fs, but that begs a question -- shouldn't
    it be added to plan9port then?

    Thanks,
    Roman.

    P.S. By the way, does is there a dedicated ML for
    plan9port or is 9fans an appropriate place
    to ask these sorts of questions?



  2. Re: [9fans] plan9port lacks exportfs server

    > somehow it dawned on me that plan9port lacks
    > an application to serve a local filesystem
    > over 9P. Is this on purpose? Am I missing
    > something fundamental that would allow
    > for a moral equivalent of exportfs?


    I pull things in as they are needed.
    I have not needed to serve 9P.
    Adding u9fs sounds reasonable, but of
    course it is already in Unix-compilable
    form elsewhere.

    Russ


  3. Re: [9fans] plan9port lacks exportfs server

    On Tue, Oct 7, 2008 at 12:24 AM, Russ Cox wrote:
    >Roman Shaposhnik wrote:
    >> somehow it dawned on me that plan9port lacks
    >> an application to serve a local filesystem
    >> over 9P. Is this on purpose?

    >
    > I pull things in as they are needed.
    > I have not needed to serve 9P.


    This reminds me, I recently compiled aux/9pcon against p9p to test
    some connections (which was delightfully easy, only some minor rfork
    changes required). The result is at
    http://sqweek.dnsdojo.org/plan9/p9p-9pcon.c should anyone be
    interested.
    -sqweek


  4. Re: [9fans] plan9port lacks exportfs server

    Hi Russ!

    First of all -- thanks a lot for answering.

    On Mon, 2008-10-06 at 09:24 -0700, Russ Cox wrote:
    > > somehow it dawned on me that plan9port lacks
    > > an application to serve a local filesystem
    > > over 9P. Is this on purpose? Am I missing
    > > something fundamental that would allow
    > > for a moral equivalent of exportfs?

    >
    > I pull things in as they are needed.
    > I have not needed to serve 9P.
    > Adding u9fs sounds reasonable, but of
    > course it is already in Unix-compilable
    > form elsewhere.


    Of course, although the utility of plan9port
    as a one stop shop for everything Plan9
    on UNIX platforms is quite significant.

    Hence the question -- would you be in favor
    of continue adding things as needed. And
    if so, what kind of of groundwork would
    you expect from the contributors?

    Thanks,
    Roman.

    P.S. I see that sqweek has the 9pcon
    and (not to overcommit myself ;-))
    I also might be able to contribute things
    like u9fs and nfsserver.



  5. Re: [9fans] plan9port lacks exportfs server

    > Hence the question -- would you be in favor
    > of continue adding things as needed. And
    > if so, what kind of of groundwork would
    > you expect from the contributors?


    Usually it is as simple as adding it to your own tree,
    adapting the mkfile, and making it build.
    U9fs is somewhat special since it is not a
    Plan 9 program. You can probably simplify things
    quite a bit by making it use the Plan 9 calls.

    Russ


  6. Re: [9fans] plan9port lacks exportfs server

    On Sat, 2008-10-18 at 10:20 -0700, Russ Cox wrote:
    > > Hence the question -- would you be in favor
    > > of continue adding things as needed. And
    > > if so, what kind of of groundwork would
    > > you expect from the contributors?

    >
    > Usually it is as simple as adding it to your own tree,
    > adapting the mkfile, and making it build.


    Absolutely! And for the internal project I'm already
    doing exactly that for nfsserver. My question had
    more to do with the usability issues, rather than
    engineering. It seems that useful bits that didn't
    get into plan9port right away tend to be scattered
    throughout "other trees" instead of being available
    at a canonical location. 9pcon comes readily to
    mind, but I'm sure there are others. Personally, I've
    only stumbled on a need to fetch 9pcon so far plus
    my own changes, but even that can be described as
    a mild inconvenience.

    Thus, I was thinking that perhaps if you could
    lay the ground rules for how new things could
    be added to your canonical plan9port tree these
    little annoyances could be dealt with.

    Thanks,
    Roman.



  7. Re: [9fans] plan9port lacks exportfs server

    > Thus, I was thinking that perhaps if you could
    > lay the ground rules for how new things could
    > be added to your canonical plan9port tree these
    > little annoyances could be dealt with.


    The ground rules are: you make it work with as
    few changes as possible from the Plan 9 original,
    and then you send me the changes.

    If you are using Mercurial, it is easiest if you
    check it into your own tree and then send me
    the output of "hg export" as an attachment.

    Russ


  8. Re: [9fans] plan9port lacks exportfs server


    Hi folks,


    I'd like to vote against feeding up p9p with more things,
    instead split it up into smaller pieces. Modern distros tend
    to have quite convenient package management systems ;-p

    I've did a few steps in this direction (but due lack of time
    not finished yet ).


    cu
    --
    ----------------------------------------------------------------------
    Enrico Weigelt, metux IT service -- http://www.metux.de/

    cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
    ----------------------------------------------------------------------
    Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
    ----------------------------------------------------------------------


  9. Re: [9fans] plan9port lacks exportfs server

    On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote:
    > Hi folks,
    >
    >
    > I'd like to vote against feeding up p9p with more things,
    > instead split it up into smaller pieces. Modern distros tend
    > to have quite convenient package management systems ;-p


    I really fail to see what is your problem here. There's no
    rule that source code repository has to correspond 1-1
    to the binary package. In fact, it is quite common
    to use a single repository for producing a number of
    different binary packages.

    If you are a binary package maintainer it is your responsibility
    to package the software in such a way that it ends up being of the
    most benefit for potential users. One of the biggest mistake
    an open source distro maintainer could make is to assume
    that his role is trivial. It is not.

    As a software developer, not a user, I do have a different
    set of constraints to optimize for. I would prefer a single
    source repository for plan9port under a reasonable DSCM
    so that I don't have to mix and match bits and pieces by
    hand.

    Thanks,
    Roman.



  10. Re: [9fans] plan9port lacks exportfs server

    * Roman V. Shaposhnik wrote:
    > On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote:
    > > Hi folks,
    > >
    > >
    > > I'd like to vote against feeding up p9p with more things,
    > > instead split it up into smaller pieces. Modern distros tend
    > > to have quite convenient package management systems ;-p

    >
    > I really fail to see what is your problem here. There's no
    > rule that source code repository has to correspond 1-1
    > to the binary package. In fact, it is quite common
    > to use a single repository for producing a number of
    > different binary packages.


    Besides the fact that I'm not making binary packages at all,
    splitted / small sources make packaging a lot easier.

    > One of the biggest mistake an open source distro maintainer
    > could make is to assume that his role is trivial. It is not.


    If the source is well designed, it actually *is* trivial ;-p

    > As a software developer, not a user, I do have a different
    > set of constraints to optimize for. I would prefer a single
    > source repository for plan9port under a reasonable DSCM
    > so that I don't have to mix and match bits and pieces by
    > hand.


    What does prevent you from having lots of separate packages
    in the same SCM ?


    cu
    --
    ----------------------------------------------------------------------
    Enrico Weigelt, metux IT service -- http://www.metux.de/

    cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
    ----------------------------------------------------------------------
    Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
    ----------------------------------------------------------------------


  11. Re: [9fans] plan9port lacks exportfs server

    On Nov 1, 2008, at 12:05 PM, Enrico Weigelt wrote:
    >> I really fail to see what is your problem here. There's no
    >> rule that source code repository has to correspond 1-1
    >> to the binary package. In fact, it is quite common
    >> to use a single repository for producing a number of
    >> different binary packages.

    >
    > Besides the fact that I'm not making binary packages at all,
    > splitted / small sources make packaging a lot easier.


    So let me get this straight: you're trying to solve a problem
    that you don't have, right?

    >> One of the biggest mistake an open source distro maintainer
    >> could make is to assume that his role is trivial. It is not.

    >
    > If the source is well designed, it actually *is* trivial ;-p


    Of course it is not. But then again, I'd rather argue that point
    with a person who knows first-hand what is involved in
    a binary packaging exercise. Here's my personal experience
    working for a company that both produces open source
    projects and builds commercial products on a foundation
    of various projects: don't ever assume that projects == products.
    IOW, don't ever assume that you can simply take a source
    code repository (however well it might be designed) and
    produce a product by simply doing ./configure ; make ;
    make install ; make pkg. Most of the time projects exist
    for other software developers, not end users. The role
    of a packager is to address the end-users and thus
    add value. The kind of value that project members are
    simply not interested in.

    >> As a software developer, not a user, I do have a different
    >> set of constraints to optimize for. I would prefer a single
    >> source repository for plan9port under a reasonable DSCM
    >> so that I don't have to mix and match bits and pieces by
    >> hand.

    >
    > What does prevent you from having lots of separate packages
    > in the same SCM ?



    Internal dependencies that are troublesome to externalize
    if you break a single source code repository into multiple
    ones. It is the same reason that makes non-changeset SCMs
    like CVS so dumb of choice for a source repository. Updates
    of a non-trivial software projects are transactional in nature.
    Breaking these transactions apart either by non grouping them
    into a changeset, or applying them to different repositories
    leads to all sorts of complications, such as inability to use
    binary search efficiently for tracking down regressions and
    the need for use of broken dynamic linking interfaces to
    describe the connections between a single transaction
    that spans different repos. But we've been there before with
    dynamic linking with you, haven't we?

    Thanks,
    Roman.


  12. Re: [9fans] plan9port lacks exportfs server

    * Roman Shaposhnik wrote:

    Hi,

    > >Besides the fact that I'm not making binary packages at all,
    > >splitted / small sources make packaging a lot easier.

    >
    > So let me get this straight: you're trying to solve a problem
    > that you don't have, right?


    No, I got a problem to be solved, but it's not to produce
    general-purpose binary packages. Instead the problem is to
    produce buildfiles for Gentoo on the one and my own embedded
    systems builder "Briegel" on the other side. Both have in
    common that they always work ontop the source (hopefully the
    upstream's source, but unfortunately often requiring additional
    patches), while Briegel has some harder constraints, eg. always
    doing crosscompiling, basing on sysroot (a kind of chroot for
    from the compiler's perspective), etc. Of course I'm building
    binary packages, too, but they're always specialized for some
    particular target system, not general purpose, not comparable
    to what common binary distros do.

    Embedded systems tend to have a lot harder constraints than
    common ws's or servers - what I'm doing is applying embedded
    constraints to them, too, since I have to face these constraints
    anyways. It's also a matter of a strict QA, which starts at
    the source.

    > IOW, don't ever assume that you can simply take a source
    > code repository (however well it might be designed) and
    > produce a product by simply doing ./configure ; make ;
    > make install ; make pkg.


    Neither do I, instead I first fix the packages so I can do this.
    Actually, my Briegel buildsystem works exactly this way:

    #1: make a fresh sysroot image (eg. install prev. built deps)
    #2: fetch the source (via the CSDB - source database)
    #3: uncompress and apply the normalized patch from OSS-QM rep.
    #4: configure stage (eg. ./configure)
    #5: build stage (eg. make)
    #6: install stage (eg. make install)
    #7: create the binary package (eg. tgz, rpm, whatever ...)

    Any package that doesn't run cleanly through this process is
    declared broken and has to be fixed first. Briegel has no
    room for workarounds, intentionally.

    > The role of a packager is to address the end-users and thus
    > add value.


    The role of a packager (for a specific package) shouldn't be
    necessary at all. With a properly designed source package,
    that job can be completely done automatically. Leaving only
    the role of the distro/system maintainer, who decides things
    like which packages to get in, where to put certain types of
    files, some default configs, etc.

    > The kind of value that project members are simply not interested in.


    I know, and that tends to be the point where I fork.

    > >What does prevent you from having lots of separate packages
    > >in the same SCM ?

    >
    > Internal dependencies that are troublesome to externalize
    > if you break a single source code repository into multiple ones.


    Which ones exactly (specifically on p9p) ?

    > Updates of a non-trivial software projects are transactional in nature.


    The key question for me is: why is the sw so complex at all ?
    More to the point: what's so complex on p9p ? From what I see,
    it's structure is quite simple (especially compared with monsters
    like mozilla), since simplicity is actually one of Plan9's major
    design goals.

    > Breaking these transactions apart either by non grouping them
    > into a changeset, or applying them to different repositories
    > leads to all sorts of complications, such as inability to use
    > binary search efficiently for tracking down regressions and
    > the need for use of broken dynamic linking interfaces to
    > describe the connections between a single transaction
    > that spans different repos.


    Wououow ... binary interfaces ... we're still at the source
    level, aren't we ?

    *If* you want to nail down a fixed binary interface, you should
    to this exactly at that point which defines the interface: the
    package (eg. library) defining it. In other words: add appropriate
    regress tests to the library package, not abusing others that just
    happen to depend on it as regress test.

    Keyword: design by contract ;-P


    cu
    --
    ----------------------------------------------------------------------
    Enrico Weigelt, metux IT service -- http://www.metux.de/

    cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
    ----------------------------------------------------------------------
    Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
    ----------------------------------------------------------------------


  13. Re: [9fans] plan9port lacks exportfs server

    [I believe we should go off-line if you're interested in continuing this
    discussion, since it has very little to do with plan9port at this point.
    I'll reply to the portion that has relevance on the list here, and will
    reply to the rest of your email privately]

    On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
    > Of course I'm building
    > binary packages, too, but they're always specialized for some
    > particular target system, not general purpose, not comparable
    > to what common binary distros do.


    So you DO build binary packages. And you WANT to build plan9port
    as a binary package? Then, you should be expected to put a reasonable
    effort into making that happen. Doing virtual Tom Sawyering and
    trying to convince developers that they should be putting that effort
    instead of you is fine tactic, I don't deny. Tom Sawyer got lucky
    doing that, you seem to be out of luck so far :-)

    > > The kind of value that project members are simply not interested in.

    >
    > I know, and that tends to be the point where I fork.


    Yep. And that's the entire point here. See, I happen to also work
    on a project where we can *afford* to be arrogant and self-serving.
    The world needs us, not the other way around. Hence we don't even
    do formal dotted releases anymore. We try to be diligent about
    tracking the progress of the external APIs by bumping a version
    number in a couple of macros, but otherwise -- all packagers have
    is our history in an SCM. It is up to them to decide that a particular
    point in that history has certain properties (like stability, or even
    fitness for a given purpose). It is up to them to fork and work
    on those properties. We, as developers, are not interested in making
    these claims. In fact, if we were making these claims without
    proper investment in QA and design specs we would be grossly misleading
    the public. We don't want to be liars.

    Now, most of the stuff written by the likes of Ken and Russ and the
    rest of the usual Plan9 suspects always works (and now, I'm not
    being sarcastic one bit here -- I'm actually constantly amazed at
    how superior these human beings are at software engineering). Thus
    when Russ says it is 0.4.1 it really *is* 0.4.1. So may be the QA
    argument doesn't apply to plan9port all that much.

    But the fitness for a particular purpose probably does.

    Only you as a packager can answer the question: who are you building
    your stuff for. And once you do -- you will see a much clearer picture
    of how it is supposed to be packaged. More to the point, that picture
    is very unlikely to have anything to do with source code development
    practices.

    Thanks,
    Roman.



  14. Re: [9fans] plan9port lacks exportfs server

    On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
    > * Roman Shaposhnik wrote:
    >
    > Hi,
    >
    > > >Besides the fact that I'm not making binary packages at all,
    > > >splitted / small sources make packaging a lot easier.

    > >
    > > So let me get this straight: you're trying to solve a problem
    > > that you don't have, right?

    >
    > No, I got a problem to be solved, but it's not to produce
    > general-purpose binary packages. Instead the problem is to
    > produce buildfiles for Gentoo on the one and my own embedded
    > systems builder "Briegel" on the other side. Both have in
    > common that they always work ontop the source (hopefully the
    > upstream's source, but unfortunately often requiring additional
    > patches), while Briegel has some harder constraints, eg. always
    > doing crosscompiling, basing on sysroot (a kind of chroot for
    > from the compiler's perspective), etc. Of course I'm building
    > binary packages, too, but they're always specialized for some
    > particular target system, not general purpose, not comparable
    > to what common binary distros do.
    >
    > Embedded systems tend to have a lot harder constraints than
    > common ws's or servers - what I'm doing is applying embedded
    > constraints to them, too, since I have to face these constraints
    > anyways. It's also a matter of a strict QA, which starts at
    > the source.
    >
    > > IOW, don't ever assume that you can simply take a source
    > > code repository (however well it might be designed) and
    > > produce a product by simply doing ./configure ; make ;
    > > make install ; make pkg.

    >
    > Neither do I, instead I first fix the packages so I can do this.
    > Actually, my Briegel buildsystem works exactly this way:
    >
    > #1: make a fresh sysroot image (eg. install prev. built deps)
    > #2: fetch the source (via the CSDB - source database)
    > #3: uncompress and apply the normalized patch from OSS-QM rep.
    > #4: configure stage (eg. ./configure)
    > #5: build stage (eg. make)
    > #6: install stage (eg. make install)
    > #7: create the binary package (eg. tgz, rpm, whatever ...)
    >
    > Any package that doesn't run cleanly through this process is
    > declared broken and has to be fixed first. Briegel has no
    > room for workarounds, intentionally.
    >
    > > The role of a packager is to address the end-users and thus
    > > add value.

    >
    > The role of a packager (for a specific package) shouldn't be
    > necessary at all. With a properly designed source package,
    > that job can be completely done automatically. Leaving only
    > the role of the distro/system maintainer, who decides things
    > like which packages to get in, where to put certain types of
    > files, some default configs, etc.
    >
    > > The kind of value that project members are simply not interested in.

    >
    > I know, and that tends to be the point where I fork.
    >
    > > >What does prevent you from having lots of separate packages
    > > >in the same SCM ?

    > >
    > > Internal dependencies that are troublesome to externalize
    > > if you break a single source code repository into multiple ones.

    >
    > Which ones exactly (specifically on p9p) ?
    >
    > > Updates of a non-trivial software projects are transactional in nature.

    >
    > The key question for me is: why is the sw so complex at all ?
    > More to the point: what's so complex on p9p ? From what I see,
    > it's structure is quite simple (especially compared with monsters
    > like mozilla), since simplicity is actually one of Plan9's major
    > design goals.
    >
    > > Breaking these transactions apart either by non grouping them
    > > into a changeset, or applying them to different repositories
    > > leads to all sorts of complications, such as inability to use
    > > binary search efficiently for tracking down regressions and
    > > the need for use of broken dynamic linking interfaces to
    > > describe the connections between a single transaction
    > > that spans different repos.

    >
    > Wououow ... binary interfaces ... we're still at the source
    > level, aren't we ?
    >
    > *If* you want to nail down a fixed binary interface, you should
    > to this exactly at that point which defines the interface: the
    > package (eg. library) defining it. In other words: add appropriate
    > regress tests to the library package, not abusing others that just
    > happen to depend on it as regress test.
    >
    > Keyword: design by contract ;-P
    >
    >
    > cu
    > --
    > ----------------------------------------------------------------------
    > Enrico Weigelt, metux IT service -- http://www.metux.de/
    >
    > cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
    > ----------------------------------------------------------------------
    > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
    > ----------------------------------------------------------------------
    >




+ Reply to Thread