[9fans] plan9port lacks exportfs server

[9fans] plan9port lacks exportfs server

[Roman Shaposhnik]

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?

Re: [9fans] plan9port lacks exportfs server

[Russ Cox]

> 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

Re: [9fans] plan9port lacks exportfs server

[sqweek]

On Tue, Oct 7, 2008 at 12:24 AM, Russ Cox <rsc@swtch.com> 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

Re: [9fans] plan9port lacks exportfs server

[Roman V. Shaposhnik]

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.

Re: [9fans] plan9port lacks exportfs server

[Russ Cox]

> 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

Re: [9fans] plan9port lacks exportfs server

[Roman V. Shaposhnik]

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.

Re: [9fans] plan9port lacks exportfs server

[Russ Cox]

> 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

Re: [9fans] plan9port lacks exportfs server

[Enrico Weigelt]

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
----------------------------------------------------------------------

Re: [9fans] plan9port lacks exportfs server

[Roman V. Shaposhnik]

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.

Re: [9fans] plan9port lacks exportfs server

[Enrico Weigelt]

* Roman V. Shaposhnik <rvs@sun.com> 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
----------------------------------------------------------------------

Re: [9fans] plan9port lacks exportfs server

[Roman Shaposhnik]

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.

Re: [9fans] plan9port lacks exportfs server

[Enrico Weigelt]

* Roman Shaposhnik <rvs@sun.com> 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
----------------------------------------------------------------------

Re: [9fans] plan9port lacks exportfs server

[Roman V. Shaposhnik]

[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.

Re: [9fans] plan9port lacks exportfs server

[Roman V. Shaposhnik]

On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
> * Roman Shaposhnik <rvs@sun.com> 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
> ----------------------------------------------------------------------
>